PAM and arla

[Christopher Allen Wing]

Charles:

> At one time our users started complaining that their AFS tokens were
> disappearing and being replaced by the tokens of different users.
> 
> The problem turned out to be our using ssh with the Dug Song's
> ssh-afs-kerberos patch.  I had logged in as root using ssh.  This had
> provided me a PAG (but no AFS tokens).  I had then restarted XDM, which
> also inherited the same PAG.  Thereafter, everyone who logged in via XDM
> shared the same PAG and so anytime someone did a klog he changed the tokens
> for all the XDM users.
> 
> Result: confusion and a possibly serious security breach.
> 
> Two other things were needed to make this happen: no separate PAG creation
> during XDM logins (nowadays we use PAM to do this) and no use of pagsh by
> users.

Right. This is why you should always use setpag() before you open up a
user's login session.

> Nevertheless, I think it's very important that, by default, root should NOT
> have a PAG.   Otherwise, any system work he does is likely to inherit the
> PAG causing all sorts of anomalies.

Yep, actually with the setgroups() wrapper for Arla this problem can still
occur. The setgroups() wrapper makes sure that the current PAG will always
persist, unless the user decides to explicitly do a setpag.

So, if you have a PAG and su to root, the root shell will indeed inherit
your tokens. For this reason I always make sure to log in as root and not
su if I am going to start up a daemon.

The best way to fix this problem in Arla is to make Arla use the UID in
addition to the first 2 supplimentary groups to determine the PAG.

At present, if the 2 magic groups are present, Arla uses them alone to
figure out which PAG the current process is in; otherwise it uses the UID.
I would suggest changing the logic so that the UID is used along with the
PAG number derived from the magic groups to find out the current PAG; i.e.
uid=4000, groups=33536 33521 is a different PAG than uid=0, groups=33536
33521.

-Chris Wing
wingc at engin.umich.edu