From mboxrd@z Thu Jan  1 00:00:00 1970
From: bogus@does.not.exist.com ()
Date: Mon,  4 May 2009 19:42:15 +0000
Subject: No subject
Message-ID: <mailman.40.1287343051.1510.9fans@9fans.net>
Topicbox-Message-UUID: 014d83e6-ead5-11e9-9d60-3106f5b1d025

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