Adding the support we had before the access= support is probably easy,
but I would like to make it better and support authentication for
multiple users. Still no idea what is the correct way. :( Any
suggestions are welcome.
I'm glad you brought this up because this is a conversation I wanted
to see. I can think of several different ways to go about
this:
- nfs style: if you authenticate to the remote as root,
you can speak for any of the uids you want to. This
assumes a common mapping of users to uids across
the machines.
twist: root squash as an option, as per nfs.
- single user: All files are presented as if owned by
a single user. This need not be the user that was
authenticated on the remote side. Any local user id
would work. Perm checks are going to be done twice,
anyway. Once locally (based on perms + the user id
assigned to all files) and once remotely (on file server)
based on the remote's idea of what user id you are (who
you authenticated as).
- multi-user authentication: A separate authenticated 9p
channel is opened for each user that makes a request over
the remote mount. This requires that some daemon have
access to credentials to authenticate each user at least
once. This daemon could be set up in advance or it could
interactively request auth info as it goes. I think
one obvious approach is to prime it with creds for a bunch
of accounts and have it fall back to the "single user"
case for all other accounts -- by mapping to some distinguished
user such as "nobody" or "guest" or "unauth9p".
by the way, I think auth method offers some room for thought
here, too. When talking with plan9 or inferno then p9sk1
or the inferno auth (whose name I forget) is the obvious choice.
However, when talking just between several non-plan9 machines
(ie. linux-linux) then other auth choices might make sense.
How many 9p servers actually use auth? Most "file servers"
are only accessed remotely through "cpu" or locally without
auth, right?
Lucho
Tim Newsham
http://www.thenewsh.com/~newsham/
