| Summary: | x11-apps/xdm - add gnome keyring unlocking support | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Daniel Pielmeier <billie> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | flippynelle, sam, zlogene |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Differences for /etc/pam.d/xdm | ||
|
Description
Daniel Pielmeier
2020-10-11 10:58:37 UTC
I believe the culprit is the rule auth sufficient pam_unix.so nullok try_first_pass in sys-auth/pambase-20201010 making the whole stack exit. From what I can seen everything from /etc/pam.d/xdm to /etc/pam.d/system-auth 'includes' the next level, nothing 'substacks'. xdm's stack is wrong, I will fix generation rules later. (In reply to Shiba from comment #1) > I believe the culprit is the rule > > auth sufficient pam_unix.so nullok try_first_pass > > in sys-auth/pambase-20201010 making the whole stack exit. From what I can > seen everything from /etc/pam.d/xdm to /etc/pam.d/system-auth 'includes' the > next level, nothing 'substacks'. Yes, your guess is right I don't mean to sound pedantic, but I think the pam_faillock mechanism as currently implemented is flawed. I would change that block as following, and I'll explain why: auth required pam_faillock.so preauth conf=/etc/security/faillock.conf auth [success=1,default=ignore] pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail auth required pam_faillock.so authsucc In case of pam_unix.so failure it goes to "pam_faillock.so authfail", same as with 'sufficient', so nothing strange here. If pam_unix.so succeeds instead, it skips the "pam_faillock.so authfail" rule and, as opposed to 'sufficient', it continues evaluating the stack. This would require no modifications to the other stacks and most importantly it allows the last rule I added (missing in sys-auth/pambase-20201010), "pam_faillock.so authsucc", which resets the authentication failure count in case of a successful authentication (see man 8 pam_faillock for more details). Fixed in the eclass. Rebuilt all consumers of pam.eclass, accepted the changes to /etc/pam.d/xdm but I still need to enter the password after login. Am I missing something? (In reply to Daniel Pielmeier from comment #6) > Rebuilt all consumers of pam.eclass, accepted the changes to /etc/pam.d/xdm > but I still need to enter the password after login. Am I missing something? Did you definitely have this https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e3e4b6550cd186b1fffcad59bbf1de9d1d757c7? I'm hoping the answer is 'no' (but that doesn't mean that's the case, it's just the easiest answer) and that combined with the latest pambase, we should be sorted.. Created attachment 665656 [details, diff] Differences for /etc/pam.d/xdm (In reply to Sam James from comment #7) > (In reply to Daniel Pielmeier from comment #6) > > Rebuilt all consumers of pam.eclass, accepted the changes to /etc/pam.d/xdm > > but I still need to enter the password after login. Am I missing something? > > Did you definitely have this > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=4e3e4b6550cd186b1fffcad59bbf1de9d1d757c7? > > I'm hoping the answer is 'no' (but that doesn't mean that's the case, it's > just the easiest answer) and that combined with the latest pambase, we > should be sorted.. I got these changes! There are however additional changes to the xdm pam configuration removing gnome keyring related stuff. See attached diff. If I readd the lines: # user generated auth optional pam_gnome_keyring.so # user generated session optional pam_gnome_keyring.so auto_start Everything works as expected! How come this lines also got removed? It does not look like the eclass is responsible for this changes. Imho this fix is really bad for the following reasons: 1) to get this change every package using pamd_mimic* needs to be rebuilt, meaning that unless every one of them gets a revision bump, users most likely would not know about it until a new upstream release; 2) packages not using pamd_mimic* (like sys-auth/pambase itself) don't get this change, making impossible for users to add custom rules after pam_unix.so in system-auth, system-login, system-local-login, ecc, since 'sufficient' will kill the stack prematurely; 3) declaring substacks changes PAM current behavior by making it evaluate everything outside of them even when it's not supposed to (for auth, account, password and session as I can see), which at the very least may have unexpected effects on already existing user configurations. Please take another look at my previous comment which also fixes pam_faillock non-consecutive failed authentication attempts. It's a pretty simple change and it shouldn't break anything that was already working with sys-auth/pambase-20200917. (In reply to Daniel Pielmeier from comment #8) > Created attachment 665656 [details, diff] [details, diff] > Differences for /etc/pam.d/xdm > > (In reply to Sam James from comment #7) > > (In reply to Daniel Pielmeier from comment #6) > > > Rebuilt all consumers of pam.eclass, accepted the changes to /etc/pam.d/xdm > > > but I still need to enter the password after login. Am I missing something? > > > > Did you definitely have this > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=4e3e4b6550cd186b1fffcad59bbf1de9d1d757c7? > > > > I'm hoping the answer is 'no' (but that doesn't mean that's the case, it's > > just the easiest answer) and that combined with the latest pambase, we > > should be sorted.. > > I got these changes! > > There are however additional changes to the xdm pam configuration removing > gnome keyring related stuff. See attached diff. If I readd the lines: > > # user generated > auth optional pam_gnome_keyring.so > > # user generated > session optional pam_gnome_keyring.so auto_start > > Everything works as expected! > How come this lines also got removed? It does not look like the eclass is > responsible for this changes. While substack was indeed needed, these changes you pointed out are pambase irrelevant, what pam configuration in xdm dos is mimic the stack, you are likely to have these lines manually added before. (In reply to Shiba from comment #9) > Imho this fix is really bad for the following reasons: > > 1) to get this change every package using pamd_mimic* needs to be rebuilt, > meaning that unless every one of them gets a revision bump, users most > likely would not know about it until a new upstream release; > > 2) packages not using pamd_mimic* (like sys-auth/pambase itself) don't get > this change, making impossible for users to add custom rules after > pam_unix.so in system-auth, system-login, system-local-login, ecc, since > 'sufficient' will kill the stack prematurely; > > 3) declaring substacks changes PAM current behavior by making it evaluate > everything outside of them even when it's not supposed to (for auth, > account, password and session as I can see), which at the very least may > have unexpected effects on already existing user configurations. > > Please take another look at my previous comment which also fixes > pam_faillock non-consecutive failed authentication attempts. It's a pretty > simple change and it shouldn't break anything that was already working with > sys-auth/pambase-20200917. I see your notice, I am sorry but I can not take them into account. (In reply to Mikle Kolyada from comment #10) > (In reply to Daniel Pielmeier from comment #8) > > Created attachment 665656 [details, diff] [details, diff] [details, diff] > > Differences for /etc/pam.d/xdm > > > > (In reply to Sam James from comment #7) > > > (In reply to Daniel Pielmeier from comment #6) > > > > Rebuilt all consumers of pam.eclass, accepted the changes to /etc/pam.d/xdm > > > > but I still need to enter the password after login. Am I missing something? > > > > > > Did you definitely have this > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > > ?id=4e3e4b6550cd186b1fffcad59bbf1de9d1d757c7? > > > > > > I'm hoping the answer is 'no' (but that doesn't mean that's the case, it's > > > just the easiest answer) and that combined with the latest pambase, we > > > should be sorted.. > > > > I got these changes! > > > > There are however additional changes to the xdm pam configuration removing > > gnome keyring related stuff. See attached diff. If I readd the lines: > > > > # user generated > > auth optional pam_gnome_keyring.so > > > > # user generated > > session optional pam_gnome_keyring.so auto_start > > > > Everything works as expected! > > How come this lines also got removed? It does not look like the eclass is > > responsible for this changes. > > While substack was indeed needed, these changes you pointed out are pambase > irrelevant, what pam configuration in xdm dos is mimic the stack, you are > likely to have these lines manually added before. You are right this were manual changes. Just did not remember as it was about 4 years ago. The user generated comment should have rang a bell, however. It looks like support for unlocking the gnome-keyring is available for other display managers like gdm (obvioulsy), sddm and lightdm. So why not add this to xdm too. @Mikle thanks for clarifying. I added the x11 team to check if it is possible to add this to xdm as well. Feel free to remove yourself from CC if you don't want to bothered with this bug any more. @X11 would it be possible to support unlocking the gnome keyring at login? The attached patch shows the required changed to the pam configuration. Would be great so it works for everyone. Additional information is available at the Gnome [1] and Arch Linux [2] Wiki https://wiki.gnome.org/Projects/GnomeKeyring/Pam https://wiki.archlinux.org/index.php/GNOME/Keyring#PAM_method (In reply to Mikle Kolyada from comment #11) > I see your notice, I am sorry but I can not take them into account. Thanks for the reply, it's way better than feeling ignored :D Then I'll open a separate report for the pam_faillock problem. Correct me if I'm wrong, but I don't think there's anything for x11@ to do here. (In reply to Matt Turner from comment #14) > Correct me if I'm wrong, but I don't think there's anything for x11@ to do > here. I wasn't sure either, but xdm can, if you are alright with it, install a pam file which will enable this behaviour to work (using pam.eclass). Or users can make the changes manually. (In reply to Sam James from comment #15) > (In reply to Matt Turner from comment #14) > > Correct me if I'm wrong, but I don't think there's anything for x11@ to do > > here. > > I wasn't sure either, but xdm can, if you are alright with it, install a pam > file which will enable this behaviour to work (using pam.eclass). I'm fine with that, but I'd prefer if someone who is familiar with what's going on here does that. This is why I added x11 in the first place. The pam file is already created by the ebuild, so it just needs this extra lines. If the pam eclass can not handle this case just add a static file in case of USE pam. I am running this since 2016 without problems, and as mentioned before other DM's also provide it. Mikle will know better but i think it can be added unconditionally as it uses the optional notation, so nothing will happen if the keyring module is not there. (In reply to Shiba from comment #13) > (In reply to Mikle Kolyada from comment #11) > > I see your notice, I am sorry but I can not take them into account. > > Thanks for the reply, it's way better than feeling ignored :D > Then I'll open a separate report for the pam_faillock problem. Did you open one yet? link please because well, counter is not reset as you said, so I'm no longer being prompted for a password after 3 failed tries: $ sudo ls Password: Sorry, try again. Password: Sorry, try again. Password: sudo: 3 incorrect password attempts $ sudo ls Sorry, try again. Sorry, try again. sudo: 3 incorrect password attempts $ sudo -K; sudo ls Sorry, try again. Sorry, try again. sudo: 3 incorrect password attempts I guess I misunderstood and it's simply a new "feature": so if password fails 3 times within 15mins, there'll be no password prompts. from /etc/security/faillock.conf # Deny access if the number of consecutive authentication failures # for this user during the recent interval exceeds n tries. # The default is 3. # deny = 3 # # The length of the interval during which the consecutive # authentication failures must happen for the user account # lock out is <replaceable>n</replaceable> seconds. # The default is 900 (15 minutes). # fail_interval = 900 deny=0 restores previoous(100days ago) behaviour. thanks |
