> 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:
(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 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).
-- 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