Re: In-kernel Authentication Tokens (PAGs)

[Andy Lutomirski <luto@myrealbox.com>]

Kyle Moffett wrote:

> I am working on a generic PAG subsystem for the kernel, something that
> handles BLOB PAG data and could be used for OpenAFS, Coda, NFSv4, etc.
> I have a patch, but it is not well tested yet.  Here is an overview of the
> architecture:
> 
> Each process has a PAG, and each PAG has a parent PAG.  Users are
> allowed to make new PAGs associated with their UID and modify ones that
> are already associated with their UID.  Each PAG consists of a set of 
> tokens,
> each uniquely identified by an integral "type" and a string "realm."  The
> search for a token by any subsystem is done starting at the immediate 
> parent
> and proceeds upward.  Tokens are in kernel memory and so are not ever
> swapped out.
> 
 > ...

I like the idea of having some kernel support for tokens.

But why PAGs?  I imagine tokens as being independent objects without any 
hierarchy.  A token group is a set of tokens.  The operations on tokens are:

read: read the raw value of the token
write: change the value of the token
execute: "use" the token (i.e. for VFS, pass over UNIX socket (to a 
privileged process, I guess).

Which gives an interesting thought: there are "anonymous" and named tokens. 
  Anonymous ones are just fds.  Named ones live in /cred/tokens.

/cred/tokens: a named token
/cred/groups/all: a magic group which has everything
/cred/groups/whatever: contains symlinks to tokens it can access

/proc/12345/tokengroup: symlink to my token group

To avoid information leaks, /cred/tokens would be readable and executable 
only by root.  You can only create symlinks to tokens you have access to. 
And you have a syscall to select a token group.

AFS's pagsh (or whatever it's called) creates a new token group and selects it.

If you really need a hierarchy, then you could allow token groups to 
contain other token groups, with the rule that the whole thing must be acyclic.

Now, if I only knew how to write filesystems...

--Andy