| Summary: | [gnome-overlay] gnome-keyring pam modules regression | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pierre Poissinger <pierre.poissinger> |
| Component: | [OLD] GNOME | Assignee: | PAM Gentoo Team (OBSOLETE) <pam-bugs+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | gnome |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://bugzilla.gnome.org/show_bug.cgi?id=514862 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 210767 | ||
| Bug Blocks: | |||
| Attachments: |
patch to revert upstream "fix"
my pam configs with "keyring" stuff emerge info The "hacked" gdm to make keyring work pambase-20080318 does not work, since gdm seems to use system-auth instead the "original" changes to pam.d files And finally, IMHO, the best: Updated (full) gdm fix gdm pam.d files to support pambase |
||
|
Description
Pierre Poissinger
2008-03-16 13:53:10 UTC
Created attachment 146309 [details, diff]
patch to revert upstream "fix"
The patch to revert upstream fix
Created attachment 146311 [details]
my pam configs with "keyring" stuff
Informtional: A tarball of the "modified" pam items to use pam_gnome_keyring.so
Created attachment 146313 [details]
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 attachment 146407 [details]
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 attachment 146516 [details, diff]
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 attachment 146519 [details, diff]
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 attachment 146521 [details]
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 attachment 146783 [details, diff]
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 :-) |
