lxdm clears kerberos ticket cache on login

Bug #937602 reported by Bo Nygaard Bai
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
lxdm (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When using kerberos login through PAM lxdm will correctly call PAM to get kerberos credentials. The kerberos credentials, notably the TGT, are written to the sessions credentials cache in /tmp/krb5cc_${UID}_xxxxxxx. This credential cache file is deleted by lxdm before starting /usr/bin/startlxde. The user experience is that although the login succeeded he can not access any kerberos secured services. This essentially makes lxdm useless in a kerberos environment.

Doing strace on the lxdm process shows that lxdm processes the login as expected through PAM which creates the credentials cache. Then lxdm forks a new process that immediatly reads the credetials file and then unlinks it, the process than goes on to exec /usr/bin/startlxde.

The result is the same whether using libpam-krb5 or libpam-heimdal

Quick fix: use gdm

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: lxdm 0.4.1-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
Uname: Linux 3.0.0-16-generic i686
NonfreeKernelModules: openafs
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Tue Feb 21 09:26:24 2012
ProcEnviron:
 LANGUAGE=en_AG:en
 PATH=(custom, no user)
 LANG=en_AG
 SHELL=/bin/bash
SourcePackage: lxdm
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Bo Nygaard Bai (bai-v) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in lxdm (Ubuntu):
status: New → Confirmed
Revision history for this message
Péter Károly Juhász (stone-midway) wrote :

Use

  auth optional pam_krb5.so minimum_uid=1000 try_first_pass retain_after_close
  session optional pam_krb5.so minimum_uid=1000 retain_after_close

retain_after_close will tell to PAM to no to clear the ticket after it completes. So it will stay.

Revision history for this message
Bo Nygaard Bai (bai-v) wrote :

Using "retain_after_close" may work as a temporary work around, but it does not fix the bug.

The fact that using retain_after_close will prevent the clearing of the credentials cache on login is a strong hint that to what the bug is. It now seems very likely that 'lxdm' is closing the just created session during initiation. The session should only be closed on logout.

Notice that using retain_after_closed has some security implications as you leave your credentials behind after closing a session.

Revision history for this message
Norman Wilson (norma7) wrote :

This problem affects us, and is quite severe: Kerberized NFS cannot work reliably and securely with lxdm unless it is fixed. Because the Kerberos cache is discarded, users cannot reliably get access to Kerberos-protected home directories. The retain_after_close workaround almost entirely bypasses Kerberos/NFS security: once someone has logged in once, Kerberos permissions associated with their userid remain for a long time (until their TGT expires) even after logout.

Fortunately I think I've also found a fix:

diff -cr ../lxdm-0.5.3-orig/src/pam.c ./src/pam.c
*** ../lxdm-0.5.3-orig/src/pam.c 2015-07-31 08:21:09.000000000 -0400
--- ./src/pam.c 2017-09-08 18:29:46.000000000 -0400
***************
*** 397,403 ****
--- 397,405 ----

  int lxdm_auth_clean_for_child(LXDM_AUTH *a)
  {
+ #if NOTDEF /*** teach.cs ***/
   pam_end(a->handle,0);
+ #endif /*** teach.cs ***/
   return 0;
  }

lxdm calls lxdm_auth_clean_for_child between fork() (to make a new process for the session) and exec of Xsession. Calling pam_end here somehow calls the close_session code in pam_krb5.so, which destroys the Kerberos ticket cache.

I don't know enough about PAM to be sure whether it's improper to call pam_end here, or whether pam_krb5 is too eager to destroy the cache. Pragmatically, though, removing that pam_end call makes lxdm usable.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.