I've just had X11 failing to start and noticed that each attempt of starting lightdm resulted in a new gnome-keyring-daemon instance being started for root. Looks like pam_gnome_keyring is at fault here.
While failing X11 is a corner case and normally people won't have ton of gnome-keyring-daemons started, I don't see why it would need to start this daemon for root when starting a login manager.
Also, it should probably be capable of cleaning up after itself. I think the session end goes through PAM anyway, doesn't it?
gnome-base/gnome-keyring-3.20.0::gentoo was built with the following:
USE="caps filecaps pam ssh-agent (-selinux) -test" ABI_X86="64"
x11-misc/lightdm-1.21.0::gentoo was built with the following:
USE="gnome gtk introspection -audit -kde -qt4 -qt5" ABI_X86="64"
Maybe it is a dupe of bug 516848... and maybe this could be checked:
please retry with pambase-20150213-r2
(In reply to Pacho Ramos from comment #3)
> please retry with pambase-20150213-r2
It doesn't fix the root issue IMHO. lightdm ebuild shouldn't replace pam.d/lightdm-greeter. I don't see the point in including system-local-login in it.
Lars, what do you think? pam.d/lightdm-greeter is only used by the greeter process, so it shouldn't include system-local-login. ebuild should just install upstream-provided config.
I see that fedora do the same:
Well, if this doesn't break my yubikey integration (which I need to test) I will merge it.
Unfortunately your PR breaks yubikey integration (which I added into system-local-login). Any chance we can fix this but still keeping system-local-login in pam.d/lightdm-greeter?
The bug has been closed via the following commit(s):
Author: Alexander Tsoy <firstname.lastname@example.org>
AuthorDate: 2018-09-25 16:09:46 +0000
Commit: Lars Wendler <email@example.com>
CommitDate: 2018-09-27 07:41:13 +0000
x11-misc/lightdm: use upstream lightdm-greeter pam config
This pam configuration file is only used by the greeter process.
Therefore is should't include system-local-login.
Package-Manager: Portage-2.3.49, Repoman-2.3.10
Signed-off-by: Alexander Tsoy <firstname.lastname@example.org>
.../lightdm/files/lightdm-1.28.0-pam-greeter.patch | 10 ++
x11-misc/lightdm/lightdm-1.28.0-r1.ebuild | 144 +++++++++++++++++++++
2 files changed, 154 insertions(+)
commit a53723eb13bfa401e1b48c0041518bafd25b96dd (HEAD -> master, origin/master, origin/HEAD)
Author: Lars Wendler <email@example.com>
Date: Thu Sep 27 10:12:44 2018
Revert "x11-misc/lightdm: use upstream lightdm-greeter pam config"
This reverts commit 39b530b86790bb5d4a909118be9457be22cf7ad3.
which was accidentally added.
Sorry for this...
(In reply to Lars Wendler (Polynomial-C) from comment #7)
> Unfortunately your PR breaks yubikey integration (which I added into
> system-local-login). Any chance we can fix this but still keeping
> system-local-login in pam.d/lightdm-greeter?
This particular bug is already fixed in pambase-20150213-r2. But I still think pam.d/lightdm-greeter shouldn't include system-local-login in the first place. IIUC the purpose of this pam config is to grant the user running lightdm-greeter GUI (if it is running as non-root user) permissions to reboot, shutdown, etc. The actual user logins should not be affected by this change.
I can re-test this once again but what can we do here if it affects yubikey integration via system-local-login?