Package: xdm Version: 4.3.0.dfsg.1-2 Severity: normal Note to self:
After bug number allocated, set submitter to "Chip Coldwell
<[EMAIL PROTECTED]>".
----- Forwarded message from Chip Coldwell <[EMAIL PROTECTED]> -----
From: Chip Coldwell <[EMAIL PROTECTED]>
To: debian-x@lists.debian.org
Subject: xdm and pam_krb5 issues
Date: Wed, 19 May 2004 12:33:57 -0400 (EDT)
Message-ID: <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----- End forwarded message -----
----- Forwarded message from Chip Coldwell <[EMAIL PROTECTED]> -----
From: Chip Coldwell <[EMAIL PROTECTED]>
To: debian-x@lists.debian.org
Cc: Brian May <[EMAIL PROTECTED]>
Subject: Re: xdm and pam_krb5 issues
Date: Wed, 19 May 2004 14:23:11 -0400 (EDT)
Message-ID: <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----- End forwarded message -----
--
G. Branden Robinson | Quantum materiae materietur marmota
Debian GNU/Linux | monax si marmota monax materiam
[EMAIL PROTECTED] | possit materiari?
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
