[5402] in Release_7.7_team
Status update on replacing Athena login with PAM modules
daemon@ATHENA.MIT.EDU (Robert A Basch)
Thu Jan 26 18:10:35 2006
Message-Id: <200601262310.k0QNAUKo021571@anhedonia.mit.edu>
To: release-team@MIT.EDU
Date: Thu, 26 Jan 2006 18:10:30 -0500
From: Robert A Basch <rbasch@MIT.EDU>
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
I have done some initial investigation of the feasibility of
replacing the Athena login library with PAM modules, thus allowing
us to use the native OS login components. So far this looks
pretty promising; it is possible that we could get most or all
of the existing library functionality that we choose to preserve using
existing native OS components in RHEL4. (This message deals only
with Linux, as the assumed target of this work; I have also looked
into using PAM to integrate a stock Solaris machine in our
environment, but will discuss that separately). It also seems
feasible to develop our own PAM modules, should we decide that the
native components will not work well enough.
On a Linux Athena machine, I tested reverting to the stock login,
enabling krb5 authentication, and using either Hesiod or LDAP for user
lookups, via the following steps:
* Revert /etc/X11/prefdm (owned by the initscripts rpm, but replaced
by athena-dm -- athena-dm does not reliably save the original
version, so I needed to reinstall initscripts).
* Install the gdm (GNOME display manager) rpm.
* Install the pam_krb5 rpm; this includes a pam_krb5afs module,
which gets AFS tokens when a session is opened.
* Run authconfig to enable krb5 authentication; this regenerates
/etc/sysconfig/authconfig, /etc/pam.d/system-auth, and
/etc/krb5.conf. Note that in order for pam_krb5afs to verify
the TGT using /etc/krb5.keytab, the "validate" option must
be enabled via krb5.conf; the latter can also be modified to
specify additional cells for which to get tokens. For example:
[appdefaults]
pam = {
validate = true
ATHENA.MIT.EDU = {
afs_cells = dev.mit.edu sipb.mit.edu
}
}
(The "validate" option may also be specified as a module
argument in /etc/pam.d/system-auth).
* To use LDAP:
- Install the nss_ldap rpm.
- Configure /etc/ldap.conf:
host ldap.mit.edu
base dc=mit,dc=edu
- Change the passwd, shadow, and group entries in /etc/nsswitch.conf
to "files ldap". (Note that the MIT LDAP server does not
currently have group records, so the non-primary groups won't
get set).
* To use hesiod:
- Create /etc/hesiod.conf (copied from
/mit/source/athena/lib/hesiod/hesiod.conf.sample)
- Change the passwd, shadow, and group entries in /etc/nsswitch.conf
to "files hesiod"
At this point, I could login to an Athena account (i.e. not present
in /etc/passwd) via gdm, with tickets and tokens via the pam_krb5afs
module; this resulted in a failsafe session (from /etc/X11/xinit/Xclients,
invoked by /etc/X11/xdm/Xsession), with just an xterm, xclock, and twm.
I was able to start up a mostly correct Athena session by doing:
a) Edit /etc/X11/gdm/gdm.conf to run /etc/athena/login/Xsession
instead of /etc/X11/xdm/Xsession (BaseXsession setting).
b) Change /etc/athena/login/Xsession to recognize command line
argument passed by gdm (i.e. "default" for a default session).
I noticed the following issues that would need to be addressed:
1) When passwd lookups are done via hesiod, the home directory
needs to be mounted on /mit/<user>, since that is the value
for home directory in our hesiod passwd records. (Currently
the MIT LDAP server's user records contain the homeDirectory
attribute value of the full AFS path (i.e.
/afs/athena.mit.edu/user/...), so the session is started
successfully without a mount, though, of course, we would still
want to be able to reference the home directory via /mit/<user>).
We could address this either by developing a PAM module (type
session, stacked after the pam_krb5afs session call), which
attaches the homedir, or by using automount. I verified that
a session could be started successfully either way, by first
writing a quick-and-dirty attach module, and then by installing
the autofs rpm, and setting up /mit as a mount point in
/etc/auto.master, with map type hesiod; in the latter test,
automount was apparently able to use our hesiod filsys
records for maps. automount does not get tokens for the
user, so we would need to rely on pam_krb5afs getting them,
and would present problems in sharing the /mit mountpoint
with attach, but these are likely manageable issues.
2) Athena login sessions records are not maintained, of course,
in /var/athena/sessions; since reactivate uses these (in
addition to utmp records, which are not created for remote
shells) to determine whether the machine is in use, we would
need to maintain these, via a PAM module, or come up with an
alternative for reactivate (perhaps parsing netstat output
for remote shell connections?).
3) The Athena console program is not run, since it is managed
by dm. I tried to run the stock xconsole program, but it only
complains that it cannot open the console, even when run as
root; I did not investigate this further. Note that gdm
redirects session output to /tmp/xses-<user>.XXXXXX.
4) I noticed a file descriptor leak, of the krb4 ticket file,
in gdm, apparently caused by pam_krb5.so. (We could deal with
this by forcing a restart of gdm between sessions, which
might be desirable for other reasons).
5) A .Xauthority file is created in the home directory; this can
be changed via the UserAuthDir setting in gdm.conf -- if the
value is /tmp, a temporary file name is generated and put into
the session's environment for this purpose.
6) gdm does not have a way to shut down the window system,
like dm's CTRL-P option. We might be able to live with its
failsafe session, combined with the ability to switch virtual
consoles.
If we are to pursue this, we would also need to consider how (or
whether) to handle the following additional login library
functionality:
- Check /etc/athena/access
- Check /etc/noroot
- Check /etc/nocreate, /etc/noremote
- Create temporary home directory when network is unavailable
Much of this functionality could likely be handled by existing
PAM modules -- pam_localuser (which requires the user to be listed
in /etc/passwd), pam_access (supports a login access control
file), and pam_mkhomedir (creates a home directory from a
skeleton if it does not exist) -- but I have not tested these
yet.
Finally, we would probably want to customize the login screen
presented by gdmgreeter; gdm supports the creation of alternate
themes, so I presume this is feasible, but I did not try it.
