Re: [9fans] permissions

[blstuart@bellsouth.net]

>> >Right.  Aside from the persistent data file servers, like kfs,
>> >kenfs, and fossil (as Erik mentioned), there's not much that
>> >treats groups in the expected way.
>>
>> So if you'll continue to pardon my asking, who exactly tells a given
>> file server what constitutes a user or a group?  In this particular
>> instance, I'm running fossil (without Venti) as the filesystem.  So
>> then, doesn't /adm/users come from fossil?  Wouldn't that mean that
>> it's fossil's responsibility to enforce permissions?
>
> in the current system, it's always the file server's responsiblity
> to maintain a list of users/groups as it sees fit.  there is no
> central authority on users or groups.  however, it's generally a
> very good idea to keep the user names in the authentication database
> in sync with your main file server.  but there's no enforcement of
> this other than the host owner of the fileserver must exist in the
> auth database and the password must match.  the host owner of
> the file server need not be in /adm/users at all!

Just to add a few bits.  A file server only learns of the user on
whose behalf the client is making requests in the attach message.
>From then on, the server can do whatever it wants with that
information.  It can implement the traditional user-group-world
permissions.  It can implement access control lists.  It can do
a user name translation and say that Bob will always get Alice's
priviliges.  It can do anything it wants, because it's handling
the open request and will either succeed it for fail it and the
client reacts accordingly.

Another thing to note is that every file server can have a different
set of users and groups.  Your fossil file system has one set
of users and groups you've defined.  When you do a 9fs sources,
you attach to another file server with a completely different
set.  In fact, there's no requirement that the intersection of
the sets be non-empty.

Finally, if we try to make the in-kernel file servers borrow
another file server's user/group list, there are some annoying
complications.  If I have several file servers, which user list
do I use?  The first thought would be to have it know about
/adm/users, but each process might have a different, or no,
/adm/users in its name space.  Plus, there's a chicken and
egg problem.  The server which gives you /dev/sd00/nvram
has to approve of the attach when fossil wants to open its
/dev/sd00/fossil, but until fossil has opened it, there's no
way of knowing what's in /adm/users on that particular fossil.

So for in-kernel file servers, it's best to look at them as hostowner
and world and forget about groups.  For lib9p based servers,
you can link in a different implementation of hasperm() and
get whatever permissions checking you want, but the default
behavior is to assume that the named group has exactly one
member: the group leader.

BLS