[6100] in Kerberos
Strange AFS 3.4, CDE, and AIX 4.1 interaction
daemon@ATHENA.MIT.EDU (Trey Harris)
Wed Nov 1 22:47:25 1995
To: kerberos@MIT.EDU
Date: 2 Nov 1995 01:35:32 GMT
From: harris@email.unc.edu (Trey Harris)
AFS version 3.4 offers a rather nifty feature for AIX 4.1 users wishing to
do authentication via kaserver or Kerberos. Plug in authentication
modules, called afs_dynamic_auth or afs_dynamic_kerbauth, can be placed in
/etc/security/login.cfg and /etc/security/user so that, on a system-wide
or user-by-user basis, the tsm program will authenticate the user to AFS
rather than to /etc/passwd. (An /etc/passwd entry must exist for the user
with the same name as the Kerberos principal, but the password itself in
/etc/passwd or /etc/security/passwd is disregarded.)
Since tsm controls the authentication of login, su, rlogind, and virtually
every other terminal-based login method, this is very convenient for AFS
users, letting them authenticate to AFS without learning a new command
set. afs_dynamic_auth authenticates to the kaserver (or
afs_dynamic_kerbauth authenticates to Kerberos), creates a PAG, and gets
an AFS token for that PAG.
In the standard AFS-ized terminal login, login is spawned by getty or
telnetd (or whatever) which sets a PAG with a token which is inherited by
the shell the user gets. Everything works great.
The point of this post is to ask about a Common Desktop Environment login.
In CDE, dtlogin spawns dtgreet, which verifies your credentials. I've
verified that on HP-UX and Solaris machines running as AFS clients,
dtgreet will not check your password with the kaserver. If your password
is not stored locally or via NIS, dtgreet will give you a login incorrect
message.
On AIX boxes running AFS, however, dtgreet gets the password from the
kaserver; I've starred out my password in /etc/security/passwd and I can
still login. I therefore hypothesize that dtgreet must be running the
tsm code for authentication, which has been AFS-ized by the plug-ins.
Following this logic, dtgreet should be creating a PAG and getting a
token, and then it will spawn a dtsession, which spawns all your clients
and shell windows. The shells and all the other clients should be
members of the PAG and be properly authenticated.
This isn't what I'm seeing, however, and what I'm seeing is a little too
odd for me to get a handle on. As I said, the CDE login is being
authenticated via AFS. However, no tokens are present in the windows I
open (via Front Panel or Application Manager) and if I klog, a UID-based
(rather than PAG-based) token is issued.
Just based on this, I would assume that either the CDE login sequence is
just authenticating to the kaserver and never getting a token, or getting
a PAG and/or token and throwing it away.
But it gets stranger: if I klog -setpag, creating a PAG and a token, then
I can use that token in all windows governed by that dtsession. This
makes me uncomfortable, because as I understood it klog -setpag should
create a PAG for this and all child processes like pagsh does, but
shouldn't be affecting parent or sibling processes.
What really makes me uncomfortable, however, is that if I log out of CDE,
log in as another user, and then back in as myself, I still have the token
from the earlier klog -setpag! (The intermediate CDE user does *not* have
access to my token, thankfully.) I've verified that in between sessions
I have no running processes.
I'm totally befuddled as to what is going on, and wonder if anyone can
take a guess. Could CDE be seeing the PAG and/or the token as something
it needs to save the state of, like the position of windows? Can dtgreet
or the plug-ins be modified so that I can login with a PAG and token?
(If that can be done, I have no problem with putting unlog into my
sessionexit file.)
Thanks...my news server is slow (isn't everybody's?) so please copy me
email if you followup.
--
Trey Harris http://sunsite.unc.edu/harris/
System Administrator, Project Isis, Office of Information Technology
The University of North Carolina at Chapel Hill
