Bug 145188 - No AFS tokens at login - saveGids() invoked too early?
Summary: No AFS tokens at login - saveGids() invoked too early?
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdm
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdm bugs tracker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-08 16:23 UTC by Hans Ranke
Modified: 2008-05-19 17:30 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Ranke 2007-05-08 16:23:04 UTC
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. */
Comment 1 Oswald Buddenhagen 2007-05-08 16:47:09 UTC
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.
Comment 2 Hans Ranke 2007-05-09 10:53:20 UTC
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.
Comment 3 Oswald Buddenhagen 2007-05-09 11:12:48 UTC
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).
Comment 4 Oswald Buddenhagen 2007-06-19 17:48:17 UTC
no convincing arguments