Bugzilla Bug 213578

A fix for gnome bug 514862 seems to have broken pam_gnome_keyring "no password
to unlock keyring" feature on my system.
e.g.: nm-applet (NetworkManager gnome applet) now requires me to type again the
keyring password to connect to protected WiFi systems...

Reverting the fix for 514862 seems to bring back the feature.

Reproducible: Always

Steps to Reproduce:
1. restart xdm/Network Manager and kill gnome-keyring then login (to recreate
initial login conditions) 
2. connect to a protected wifi
3. get a annoying "unlock keyring" password entry

Actual Results:  
Beeing piss off by a "I know you just typed the password but maybe it's not
you... please reenter the same password so I am sure..."

Expected Results:  
be connected on my wifi

Created an attachment (id=146309) [edit]
patch to revert upstream "fix"

The patch to revert upstream fix

Created an attachment (id=146311) [edit]
my pam configs with "keyring" stuff 

Informtional: A tarball of the "modified" pam items to use pam_gnome_keyring.so

Created an attachment (id=146313) [edit]
emerge info

FYI: emerge info

<fr_FR>Génial!!</fr_FR>

Thanks for looking into this, I'd been slacking off on that bug, which had been
pissing me off too for a little while.

We'll track this bug upstream, although I think I'll ask Diego/flameeyes (our
PAM resident) to add himself CC to the upstream bug too. I'm somewhat fearing
that the issue is configuration related.

Either way, thanks for the patch, I've just pushed it to the overlay.

(In reply to comment #4)
You're welcome...

I also fear the problem is in "our/my" PAM stack config... I just don't
like/know PAM enough to break my system just for the sake of finding out the
exact reason... and not sure that upstream has time to teach me the pam stack
magics ;-)

Btw, kudos for the overlay, the 2.22 seems pretty rock solid on my system :-)

@Diego,

If you have a minute, I'd like for us to find a real fix for this and since you
know PAM better than anyone I know, I humbly request your help with this
regression :)

Thanks

Created an attachment (id=146407) [edit]
The "hacked" gdm to make keyring work

Upstream finally gave an example (of ubuntu... grr) and got it working... but
not the way I like: For pam_gnome_keyring to work, I had to remove the
system-auth includes, since using "sufficient" render pam_gnome_keyring
useless... Will be glad to have the opinion of a PAM wizard :-)

Right... we need to figure this out then.

Absolutely unacceptable to remove system-auth/system-local-login (for pambase)
include in the auth chain.
Does it work if you do

auth optional pam_gnome_keyring.so
auth include system-auth

?

important comments from the upstream bug:

------- Comment #14 from Gilles Dartiguelongue  2008-03-17 21:07 UTC -------
ok, I think I know what's happening. In gentoo's case, the current approach in
stable pam config doesn't allow putting something after the
common-auth/system-auth _but_ here it looks like what gnome-keyring does is
just takes the password and tries to unlock the keyring with it and it can only
have it if another pam module read/asked it first (correct me if I'm wrong)

In the usual case it's pam_unix, but it might be pam_ldap or
pam_${whatever_ask_passwords_by_itself}. Now I/we gnome herd need to fix that
with diego on gentoo.


------- Comment #15 from Stef Walter  2008-03-17 23:02 UTC -------
Yes, that's correct. To reiterate, pam_gnome_keyring takes the password and
tries to unlock the keyring with it. Another module must have already prompted
for the password and username.

now the only thing is that I'm not sure the new pambase stuff allows the user
to have pam modules _after_ invoquing identification modules (eg.
pam_unix/pam_ldap). Of course the user could rewrite the gdm pam config to not
use the common config and do that by itself but that would be silly ihmo. (and
no I didn't tested yet, I was playing nfsu2 :D)

Okay, so can you depend on pambase? I don't have it at hand (I'm from the
laptop), but if right now it's ran _before_, I can easily fix it to run after
pam_unix and other modules, then I can release a new pambase, you can depend on
that, and we'll all be fine.

(And it's a satisfaction, to know that pambase solves the problem before it was
known to me ;) ).

(NB, I haven't tried pambase with gnome-keyring yet, I'll be assuming it works)

Basically, a few gnome components actually dep on gnome-keyring. So I'm not
entirely sure how to handle the deps for all that.

How does PAM handle a missing .so ?

Depends on the success/failure keyword. An optional module won't create problem
if the .so is missing.
But that should be beside the point: use of gnome keyring in the pambase auth
files is provided by the gnome USE flag: with it it's enabled, without it's
disabled.

Yeah, I understand how your CPP-based code works, it's pretty cool. I'm just
wondering if pam-base depending on a rather high-level part of gnome (keyring)
won't cause too much problem.

If not, then it's all good :) I'll just update my small howto and possibly add
an einfo to gnome-keyring.

Well, pambase has no _DEPEND_, it only has _R_DEPEND. And stuff should never
_DEPEND_ on it, but only _R_DEPEND, so it should be pretty easy to bail out of
the circular deps, I think.

Please check out pambase-20080318.

Created an attachment (id=146516) [edit]
pambase-20080318 does not work, since gdm seems to use system-auth instead

Ok, by default pambase does not "fix" the problem, moving the changes didn't
help since gdm (the one I use) seems to go to system-auth and not system-login
[Disclamer: I didn't check this patch, just "manually" update the /etc/pam.d
and pushed the change I made in pambase... original "changed" patch to my pam.d
arrives

Created an attachment (id=146519) [edit]
the "original" changes to pam.d files

The original changes - Probably it cannot apply "clean" since I have a "update"
to system-login to keep pam_lastlog silent (not in pam.d), I just hate when
sudo give me the lastlog thingy :-)

Created an attachment (id=146521) [edit]
And finally, IMHO, the best: Updated (full) gdm

Technically, as long as system-auth does not contains "sufficient" keyword
(like the 20080318, it's fine), I think the call to pam_gnome_keyring can be
put only in gdm, just to be "clean"
(Now I didn't look how the pam is added and if it contains smart code as
pambase...)
-- So, in the end, this will/may need an update to gdm in addition of an
re-updated pambase (to remove keyring stuff, but keep the new ways)

Anyway, thx to all the devs looking at my "stupid" issues :-) 

The fix is for gdm to use system-login _as it's supposed to by now_ rather than
system-auth. Most login software has been switched to system-login already.

(In reply to comment #20)
> The fix is for gdm to use system-login _as it's supposed to by now_ rather than
> system-auth. Most login software has been switched to system-login already.
> 
Ok for me... 
Btw, IMPCO (In My Political Correct Opinion aka I don't want a flame from KDE
believers) gdm should still be the only one to have the "gnome_keyring"
stuff... and my "!PC" opinion is "as long as I don't have to enter my pass 20
times I am happy with whatever you guys thinks the best" ;-)

gdm, kdm, login(1), ssh, they are all login systems, they should all run the
same stack, as long as it's optional via USE flag, I don't see why it shouldn't
be run every time...

fair enough for me - I am just unsure of the use to have a gnome-keyring-daemon
starting with login/ssh (where the actual use of it is less obvious IMHO)

But honestly, I just like to be picky :-)
Now to come back to earth, should I post a new bug for GDM and the
"system-login" pam stuff ? 

I'd hate to burst our bubble but it doesn't work. I've tried removing the
"fixpam" patch and even with yesterday's pambase (20080318), the keyring still
wants my password.

Nothing in syslog this time around though... that worries me.

(In reply to comment #24)
> I'd hate to burst our bubble but it doesn't work.
To make it work, there is still one bug: gdm does not include the "correct" sub
stack in his pam: Should be system-login instead of system-auth

system-local-login to be precise.

Ok, great :) It works.

Diego, do you have a plan to migrate the other pam-using packages to pambase? I
don't like the idea of having just GDM using pambase stuff while all the other
packages use system-auth.

*cough* I asked for gdm to be ported in February already. Check bug #210767
deps to see what is using system-auth already :P

I think the main packages not yet ported are gdm, kdm (which has at least one
bad behaviour with it) and xdm (which crashes with it because of a bug in xdm
and challenge auth). ssh, login, rsh, wdm were ported already.

Confirming it works great here as well, the only thing is that I find
pam_access is a bit odd to get from gdm.

Anyway, people might also want to check :
http://bugzilla.gnome.org/show_bug.cgi?id=516102 and
http://live.gnome.org/GnomeKeyring/Ssh

to know how to automatically unlock ssh keys like what seahorse did in 2.20.

Created an attachment (id=146783) [edit]
fix gdm pam.d files to support pambase 

Ok, since I don't see a "fixed" gdm to support the pambase (and dear
gnome-keyring) out of the box, here comes my patch to gdm-2.8-gentoo-files-r2.

Most probably this tarball needs to be patched and bumped to -r3 and
distributed...

Anyway, for testing, the following changes in gdm ebuild should apply it to
current -r2: [to glue at the end of src_unpack, pretty sure I am violating _at
least_ 25 ebuild rules ;-)]
---[cut here]----
        # Fix pam stuff
        # go back to work dir to apply the patch on gdm-2.8-gentoo-files-r2
        cd "${S}/.."
        epatch "${FILESDIR}/${PN}-2.20.3-pam.patch"
        # go back
        cd "${S}"
---[cut here]----

Yeah, I was planing on doing the same patch. I'll take care of it tomorrow,
probably with an updated dep on pambase as well.

Thanks for trying it out.

gdm-2.20.4 that is planned to go along with gnome-2.22 has been commited to the
tree with the necessary changes to fix this. As a consequence, keywords on
archs that didn't had pambase-20080318 keyworded were dropped.

For reference, it concerns "~arm ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc". I think
we'll open a new bug report for this.

Thanks, closing the bug :-)