On Fri, Aug 13, 2004 at 11:33:19AM +0200, Jan Kopriva wrote:
> So if I got it well, after the user clog to the server the tokens he/she
> acquired from the auth server are propagated to venus.
> So that's why root (or any one else who knows users's password) can su to
> user and thus get the rights to access users distributed files, right?

Correct, venus associates a token with the local userid that passed the
token. Every request coming from that uid will be sent over a connection
that was set up with the given token. A root user using 'su' will change
it's effective or fsuid to that of the local user and as such will be
given the same permissions.

> If the tokens were not stored on the disk but kept in memory (in user's
> task struct) the simple switch to user wouldn't help anyone, right?

We can't even get a PAG in the kernel task struct, so forget about
storing tokens there. Besides each realm requires its own token, but the
kernel doesn't really know anything about which objects are part of a
realm.

> Is there any way to force venus not to cache any thing?
> Also I guess AFS works almost the same way, doesn't it?

Not really, AFS uses a process authentication group. The idea is that
there is a syscall through which a process can request a 'newpag', this
is a unique identifier that identifies this process and all its
children (except for those that called newpag themselves). If newpag is
associated with something like login, we can track that root did a 'su'
to some user, but his identity is different from that of the user. Or we
can have one user with several sessions (local login vs. remote login,
or one session with admin tokens and other sessions with regular tokens).

I believe that PAGs are decribed in

    Integrating Security in a Large Distributed System  (# 12)
    Satyanarayanan, M.
    ACM Transactions on Computer Systems
    Aug. 1989, Vol. 7, No. 3, pp. 247-280 
    http://www-2.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/sec89.pdf

Over time people watered down the security model, DFS added the ability
to join an existing PAG so that users could remotely log in and refresh
their tokens and such, making (IMHO) the whole thing pretty much useless
from a security/authentication perspective.

When we wanted to push 'classic pags' to Linux, DFS and cluster people
showed up and turned the simple changes in such a flamefest that Linus
threw his hands up and decided that he didn't like the idea at all and
that the kernel should get some more generic 'key/token bucket'
mechanism which could also be used by encrypted local filesystems,
network connections, and whatever else. Some attempts are currently
ongoing, but I don't think they will ever be useful for our purposes
simply because we really only need a simple _guaranteed unique_
identifier.

Jan