(Illustration by Gaich Muramatsu)
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. JanReceived on 2004-08-13 16:08:56