Package: xdm Version: 4.3.0.dfsg.1-2 Severity: normal Note to self: After bug number allocated, set submitter to "Chip Coldwell <coldwell@physics.harvard.edu>". ----- Forwarded message from Chip Coldwell <coldwell@physics.harvard.edu> ----- From: Chip Coldwell <coldwell@physics.harvard.edu> To: debian-x@lists.debian.org Subject: xdm and pam_krb5 issues Date: Wed, 19 May 2004 12:33:57 -0400 (EDT) Message-ID: <[🔎] Pine.LNX.4.44.0405191233380.3693-100000@localhost.localdomain> X-Mailing-List: <debian-x@lists.debian.org> archive/latest/18558 X-Spam-Status: No, hits=-1.0 required=4.0 tests=LDOSUBSCRIBER autolearn=no version=2.63-lists.debian.org_2004_05_14_06 Hi, I'm having problems using libpam-heimdal (Kerberos v5) with xdm under Debian (Sarge). I've tracked down the problem precisely, and I am proposing a specific fix; this isn't a cry for help. The symptom is the following. If the file /etc/pam.d/xdm contains the line auth sufficient pam_krb5.so debug at the top, the function "pam_setcred" is called twice by xdm, first in the function Verify at about line 500 in the file xc/programs/xdm/greeter/verify.c then again in the function StartClient at about line 596 in the file xc/programs/xdm/session.c What happens is that the function pam_sm_setcred in libpam-heimdal-1.0/pam_krb5_auth.c checks to see if a Kerberos credentials cache already exists, and if it does the function fails. Since it is called twice, the credentials cache is created by the first call, then the second call causes pam_sm_setcred to fail, and with it the login fails. It turns out that this behavior (checking for the existence of a credentials cache in pam_sm_setcred and failing if it exists) is added by a Debian patch, namely the last hunk of "destroy-ticket.patch" that comes with libpam-heimdal. If I build libpam-heimdal without this hunk, then everything works fine. In addition, after logging in with xdm, the credentials cache contains the TGT and host tickets I expect. So we should either remove this hunk from libpam-heimdal so that it doesn't care if the ccache exists already, or xdm should not call pam_setcred twice (once for authentication and once for session). Chip -- Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388 -- To UNSUBSCRIBE, email to debian-x-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org ----- End forwarded message ----- ----- Forwarded message from Chip Coldwell <coldwell@physics.harvard.edu> ----- From: Chip Coldwell <coldwell@physics.harvard.edu> To: debian-x@lists.debian.org Cc: Brian May <bam@snoopy.apana.org.au> Subject: Re: xdm and pam_krb5 issues Date: Wed, 19 May 2004 14:23:11 -0400 (EDT) Message-ID: <[🔎] Pine.LNX.4.44.0405191346360.10168-100000@localhost.localdomain> X-Mailing-List: <debian-x@lists.debian.org> archive/latest/18562 X-Spam-Status: No, hits=-1.0 required=4.0 tests=LDOSUBSCRIBER autolearn=no version=2.63-lists.debian.org_2004_05_14_06 On Wed, 19 May 2004, Chip Coldwell wrote: > > So we should either remove this hunk from libpam-heimdal so that it > doesn't care if the ccache exists already, or xdm should not call > pam_setcred twice (once for authentication and once for session). After some more investigation, I've decided that the right solution is to remove one of the two pam_setcred calls from xdm. The reason is that pam_setcred as implemented by libpam-heimdal's pam_krb5 module creates a credentials cache in /tmp/krb5cc_XXXXXX using tmpnam(3) and then sets the value of the environment variable KRB5CCNAME to the name of this file. If pam_setcred is called twice, two files with different names (containing the same credentials) are created, but the environment variable only holds one filename, of course (its value is overwritten by the second call to pam_setcred). Therefore, a call to kdestroy(1) will only destroy one of the two credentials caches -- leaving the other one in /tmp even after a logout. This is a security risk and definitely not desirable. The question of which of the two pam_setcred calls to remove depends on the exact semantics of how PAM expects this function to be used. Even though holding a credentials cache for the duration of a login sounds like a session function, as far as I can tell, pam_setcred is part of the authentication component of PAM. Therefore if we want to stick to the authentication semantics, then the right pam_setcred call to remove is the one in xc/programs/xdm/session.c Additionally, I would argue that holding a credentials cache really should be a function of the session component of the pam_krb5 module. Right now the open_session and close_session functions in pam_krb5 (from libpam-heimdal) are no-ops .... Chip -- Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388 -- To UNSUBSCRIBE, email to debian-x-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org ----- End forwarded message ----- -- G. Branden Robinson | Quantum materiae materietur marmota Debian GNU/Linux | monax si marmota monax materiam branden@debian.org | possit materiari? http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature