I concur that it is probably an attempt to solve a problem that can be
solved in other ways.
There are several things you could do to have the user's privileges:
1. With the KeyFile on any of the AFS servers, you can construct
Kerberos tickets and/or AFS tokens that will work with the servers.
(I have such a utility for automatic tree management on a SECURE
machine, and I don't trust IP addresses... I wrote it before I
could think of a use for it... If you compromise the machine, you
will have already in effect have compromised the cell because it is
one of the AFS servers...)
2. If you need the user's environment, because you suspect it relates
to that PARTICULAR session, you need to get yourself into their PAG.
Essentially, if you know the process, you could look up the grouplist
in the u-area of that process, spawn another process with that
grouplist, and you will be in their PAG. Basically, the PAG
information is encoded in the first two groups of the process's
grouplist information in the u-area. Of course, to set a grouplist,
you have to use the setgroups() call, which has to be done as root,
and for it to be useful afterward, you need to exec some program,
such as a shell after that call... It turns out that if you do a
setgroups() and the first two groups form a valid PAG that it will
supercede any previous PAG information. In essence, you can enter
into a new PAG. However, if they do not encode into a valid PAG,
and you are already in one, the call will prepend the two groups that
form the current PAG. In other words, once in a PAG, you cannot
revert back to the default NOPAG case... If you are completely
lost, that's ok... it is probably not something you want to play with.
-Richard
