Re: PROPOSAL: Process Authentication Groups (PAGs) (fwd)

Peter J. Braam (braam@cs.cmu.edu)
Fri, 20 Feb 1998 15:00:22 -0500 (EST)


On 20 Feb 1998, Aaron M. Ucko wrote:

> Robert Watson <robert@cyrus.watson.org> writes:
>
> > appear to be that there is a need for finer granularity management of keys
> > than a mere mapping to UID (which is what Coda currently does).
>
> Absolutely. However, it's not clear PAGs a la AFS are the right
> solution. IMO, token sets (TS's for short, pending a better name)
> should have the following properties:

The purpose of a PAG is NOT to do token management, but to provide
identity to token managers.

>
> (1) It should be possible to create and destroy a TS, and populate
> it with credential information.
>
> (2) A user should be able to have multiple TS's.
>
> (3) A process should generally inherit its parent's TS.
>
> (4) User A should not be able to access a TS belonging to user B at
> all, except possibly if A is root or B has explicitly let A.
>
> (5) A user should be able to switch TS's on the fly.
>
> (6) TS's should take up as little kernel space as possible.

PAGS certainly meet 6.

>
> PAGs satisfy (1), (2), (3), and (4) (barring wraparound), and can
> satisfy (6), but don't really satisfy (5). I see two sane ways to
> satisfy (5) with existing shells:
>
> (a) Have a variable mapping from sessions or process groups to
> TS's; this requires either the kernel or the cache manager to
> keep track of more state, and has the disadvantage (shared
> with AFS PAGs) that there's no way to start processes which
> should have different TS's from the same shell.
>
> (b) Have the kernel look at the value of some environment variable
> to determine which of a user's TS's to use. This method has
> the disadvantage that there's no way for a process to change
> TS's, because the kernel only sees the initial value of the
> variable; I suppose it would be possible to provide an
> additional, independent, mechanism for that, though. It also
> requires us to be more careful about (4).

In due course there will be many different types of tokens. I think that
the extra layer of abstraction formed by the PAG will allow easy token
management for a while to come.

If you centralize things in the kernel, you would have different problems:
how would you use one token for AFS and another for Coda etc.

>
> --
> Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu