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?
================================================================= Package Settings ================================================================= 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: https://bugs.gentoo.org/show_bug.cgi?id=516848#c7
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: https://src.fedoraproject.org/rpms/lightdm/blob/master/f/lightdm.spec
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): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=39b530b86790bb5d4a909118be9457be22cf7ad3 commit 39b530b86790bb5d4a909118be9457be22cf7ad3 Author: Alexander Tsoy <alexander@tsoy.me> AuthorDate: 2018-09-25 16:09:46 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> 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. Closes: https://bugs.gentoo.org/600216 Package-Manager: Portage-2.3.49, Repoman-2.3.10 Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Closes: https://github.com/gentoo/gentoo/pull/9973 .../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 <polynomial-c@gentoo.org> 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?
What action is pending here? Is this still valid?
Well, right now I don't see any root-started gkd.
