Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 747793 - x11-apps/xdm - add gnome keyring unlocking support
Summary: x11-apps/xdm - add gnome keyring unlocking support
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-11 10:58 UTC by Daniel Pielmeier
Modified: 2020-11-23 05:21 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Differences for /etc/pam.d/xdm (xdm.diff,528 bytes, patch)
2020-10-14 19:33 UTC, Daniel Pielmeier
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Pielmeier gentoo-dev 2020-10-11 10:58:37 UTC
As the title says after login with xdm I get the message that the login keyring has not been automatically unlocked and I have to unlock it manually.

After restoring sys-libs/pam-1.3.1_p20200128-r1 and sys-auth/pambase-20200304 it worked again.
Comment 1 Shiba 2020-10-11 19:06:13 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'.
Comment 2 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-10-11 19:09:28 UTC
xdm's stack is wrong, I will fix generation rules later.
Comment 3 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-10-11 19:11:07 UTC
(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
Comment 4 Shiba 2020-10-11 20:46:07 UTC
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).
Comment 5 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-10-14 18:24:25 UTC
Fixed in the eclass.
Comment 6 Daniel Pielmeier gentoo-dev 2020-10-14 19:21:54 UTC
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?
Comment 7 Sam James archtester gentoo-dev Security 2020-10-14 19:25:55 UTC
(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..
Comment 8 Daniel Pielmeier gentoo-dev 2020-10-14 19:33:37 UTC
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.
Comment 9 Shiba 2020-10-14 19:45:54 UTC
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.
Comment 10 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-10-14 19:46:40 UTC
(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.
Comment 11 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-10-14 19:47:58 UTC
(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.
Comment 12 Daniel Pielmeier gentoo-dev 2020-10-14 21:15:19 UTC
(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
Comment 13 Shiba 2020-10-14 21:29:14 UTC
(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.
Comment 14 Matt Turner gentoo-dev 2020-10-14 21:46:27 UTC
Correct me if I'm wrong, but I don't think there's anything for x11@ to do here.
Comment 15 Sam James archtester gentoo-dev Security 2020-10-14 22:01:48 UTC
(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.
Comment 16 Matt Turner gentoo-dev 2020-10-14 22:50:48 UTC
(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.
Comment 17 Daniel Pielmeier gentoo-dev 2020-10-15 05:13:59 UTC
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.
Comment 18 flippynelle 2020-11-23 02:47:06 UTC
(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
Comment 19 flippynelle 2020-11-23 02:55:35 UTC
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
Comment 20 flippynelle 2020-11-23 02:57:51 UTC
deny=0 restores previoous(100days ago) behaviour. thanks