>> >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
