From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 17 Oct 2010 14:18:32 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <621112A569DAE948AD25CCDCF1C075332999FD@dolly.ntdom.cupdx> References: <299d2867aa8f8587f6cb67bff55ca368@bellsouth.net> <621112A569DAE948AD25CCDCF1C075332999FD@dolly.ntdom.cupdx> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] permissions Topicbox-Message-UUID: 68735fd6-ead6-11e9-9d60-3106f5b1d025 > >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? the case of fossil and fossil+venti are the same. venti just changes how stuff is stored. 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! - erik