| Summary: | No AFS tokens at login - saveGids() invoked too early? | ||
|---|---|---|---|
| Product: | [Unmaintained] kdm | Reporter: | Hans Ranke <Ranke> |
| Component: | general | Assignee: | kdm bugs tracker <kdm-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
imo, the pam module is broken. gids should be set in pam_setcred, not pam_open_session. please check with the author of this pam_krb5 module. Well, in theory, you are probably right, this is about setting credentials. However, there are reasons why PAG setup is often done in the session management components of PAM. What pam_krb5 does for AFS, is (among others) setting up a PAG (process authentication group). A PAG is a credential that is an attribute to the session - not to an user account. On modern linux kernels, PAG setup involves both setting up a special key in the process' keyring and setting a session-specific Group ID. Pam_krb5 will optionally do the PAG setup in pam_setcred(). But then the PAG key will be destroyed by pam_keyinit during session setup. Thus, PAG setup needs to be performed in the session setup, after pam_keyinit. credentials are always set up in preparation of opening a session. they may depend upon time, location and the weather if the sysadmin wishes so. an additional hint that my interpretation of the pam manuals is correct is the existence of PAM_REFRESH_CRED and a lack of PAM_REFRESH_SESSION or something to that effect. if other modules do the same, they are equally broken. in fact, i've seen no external module that gets the credentials and session setup even remotely right. i tend to close this as INVALID unless some convincing arguments are brought up. compatibility with utterly broken code is no convincing argument (unless is poses a security risk). no convincing arguments |
Version: (using KDE KDE 3.5.6) Installed from: Fedora RPMs Compiler: GCC 4.1.1 OS: Linux I would like to get an AFS token on login with pam_krb5. Since the update from kdebase-3.5.4-12.fc6 to kdebase-3.5.6-0.1fc6 this does not work any more. pam_krb5 needs to assign a group in pam_open_session(). Debugging shows that the group is correctly set while subsequent pam modules are executed, but gets lost until the user session starts. Looking at the source of StartClient() (file kdm/backend/client.c) I saw that the function saveGids() is invoked after the groups have been set by SetGid(), but before pam_open_session(). Later, these saved gids are restored, so that modifications to the group list during pam_open_session() are lost. The appended patch, that moves the saveGids() invocation until after pam_open_session(), fixes the bug. However, I am perhaps not aware of all implications of this change (for example I do not understand the comment that pam_setcred(DELETE_CRED) may need the saves gids). I am using: Fedora Core 6 kdebase-3.5.6-0.1fc6 pam_krb5-2.2.11-1 openafs-1.4.4 Proposed patch: --- kdm/backend/client.c.orig 2007-05-08 09:28:28.000000000 +0200 +++ kdm/backend/client.c 2007-05-08 09:31:04.000000000 +0200 @@ -1287,15 +1287,6 @@ pam_env = environ; environ = saved_env; # endif -# ifdef HAVE_INITGROUPS - /* This seems to be a strange place for it, but do it: - - after the initial groups are set - - after pam_setcred might have set something, even in the error case - - before pam_setcred(DELETE_CRED) might need it - */ - if (!saveGids()) - return 0; -# endif if (pretc != PAM_SUCCESS) { LogError( "pam_setcred() for %s failed: %s\n", curuser, pam_strerror( pamh, pretc ) ); @@ -1312,6 +1303,15 @@ resetGids(); return 0; } +# ifdef HAVE_INITGROUPS + /* This seems to be a strange place for it, but do it: + - after the initial groups are set + - after pam_setcred might have set something, even in the error case + - before pam_setcred(DELETE_CRED) might need it + */ + if (!saveGids()) + return 0; +# endif /* we don't want sessreg and the startup/reset scripts run with user credentials. unfortunately, we can reset only the gids. */