[OpenAFS-devel] Nothing but the PAG

[Garance A Drosihn]

At 11:24 AM -0400 5/16/03, Jan Harkes wrote:
>On Thu, May 15, 2003, Nathan Neulinger wrote:
>  > I like this, it also makes it trivial to add a module later on
>  > that can get in there and do a setpag() if that is ever needed
>  > without having to have that be in the patch.
>
>In reality, a pag is used to work around a bunch of solvable
>problems,
>
>- To make sure that an application that uses setuid doesn't lose
>   it's original credentials. Why not just remove the setuid calls.

Because you need the setuid for other reasons.  Consider a command
like 'lpr', which is setuid so it can copy files into the local
unix file system.  Any application that calls setuid() is making
the call for it's own reasons -- reasons that have nothing to do
with AFS file access.  You just can't tell programmers that they
are not allowed to use setuid() because AFS is too lame to deal
with the side-effects.  (and AFS without pags would be too lame)

>- To provide a 'private' session to do administrative stuff. How
>   about creating a new local login, <user>-admin and simply use
>   'su user-admin' before getting the admin tokens.

I think of this in a different way than you seem to.  We create
special AFS accounts because there is no special 'root' account
that can do administrative things from.  And as long as we have
to create an account for AFS-admin things, we might as well
create specific admin accounts which are specific to each user
who has admin access, instead of having just one 'afs-root'
account.  In my mind, user-admin accounts have nothing at all to
do with PAG's, and everything to do with "good security sense".

>- To prevent a local daemon that is started by the user from
>   accessing his private files. Again, new local userid and done.

I think that would be a much worse solution than just using PAG's.
You're going to create multiple accounts, with multiple passwords,
just to work around problems with AFS?  One for each user?  Or
maybe even more than one for each userid (so different daemons
won't trip over each other)?  We have 15,000 active userids at
RPI, and we are certainly not eager to make that 30,000 just
for AFS.

>So yes, I'm assuming that the user has administrative rights on
>his machine, but the whole point of the AFS design was that
>clients were untrusted in the first place.

The AFS design point is that AFS clients are not trusted (much)
by the AFS file server.  That does not mean that all users have
administrative access to the password file on the machine they
log into.  The user-accounts in an AFS cell are not tightly
coupled to the user-accounts on the individual AFS clients, and
that is a good thing.  That is how I could authenticate to an
AFS userid in umich.edu even though my own client machine is
in the cell for RPI.edu.

However, we have thousands of AFS users at RPI, and hundreds of
machines where they can log into and they will not have any
administrative access to those (afs-client) machines.  We are
not going to give administrative access to a few thousand people
just to work around the problems that would be created if afs
were to drop the concept of a PAG.

The concept of a "per-session container" is an extremely useful
thing to have.  If unix had that, then I'm sure a number of
services would gravitate to using it.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu