[OpenAFS-devel] Nothing but the PAG

[Jan Harkes]

On Fri, May 16, 2003 at 11:30:08AM -0400, Derrick J Brashear wrote:
> On Fri, 16 May 2003, Jan Harkes 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.
> 
> su works poorly when it's not setuid.(*) i want to become root and keep
> my authentication. i hate typing my password. just ask the pubkooky (er,
> sorry, pubcookie) boosters.

It seems to me that pags have in general not been used the way they were
originally intended.

Traditionally a token was shared among all processes with the same uid,
except in the special case that a process had a non-zero pag. The only
way to get a non-zero pag was by using su or when specifically
requesting a new pag while obtaining new AFS tokens.

As a result it was easy to refresh tokens for all processes even when
logging in remotely, and pags were only used in very special cases to
(temporarily) isolate a process and it's children from either seeing or
influencing the tokens of other processes with the same uid and from
losing credentials when changing uid.

A root user using 'su user' wouldn't accidentally gain access to that
user's files, but sendmail with plain old setuid would. Also the other
way around, a user becoming root with su will not share his credentials
with other root processes such as the various system daemons that are
always running.

The semantics of the isolated pag environments happen to provide the
ability keep existing tokens when changing userids. So people added
newpag() to login and so a pag became associated with the login session.
Great, but now we suddenly are faced with the problem that we can't
refresh tokens in other pag-sessions because of the intended isolation
properties of the original design.

That's a bummer, now the ability to join a pag suddenly becomes
important because we want the ability to log in remotely and refresh
the tokens of all our processes on the system.

As the ability to join an existing pag was added, security models went
IMHO totally down the drain. Clients are supposed to be untrusted which
is why credentials are only obtained from special remote authentication
servers. But joining a pag is policed by local policy such as superuser
rights and doesn't depend in any form on remote authentication. We also
lost the isolation properties of a pag session, which really makes the
whole case for a pag very questionable because it really never was
designed to provide much beyond an isolated environment.

If su had been modified to carry existing tokens into the newly
created pag, people might not have bothered to rely on pags exclusively
and this need to join an existing pag would not have existed.

Jan