Date: Wed, 18 Jun 1997 15:10:04 +0100 From: Josef Karthauser <joe@pavilion.net> To: Drew Derbyshire <ahd@kew.com> Cc: hackers@FreeBSD.ORG Subject: Re: granting auth to processes Message-ID: <19970618151004.21788@pavilion.net> In-Reply-To: <33a61180.kew-sonata@sonata.uucp.kew.com>; from Drew Derbyshire on Tue, Jun 17, 1997 at 12:24:32AM -0500 References: <33a61180.kew-sonata@sonata.uucp.kew.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 17, 1997 at 12:24:32AM -0500, Drew Derbyshire wrote: > > Consider it's the multiple levels of access needed to a set of files: > > User O can create or delete file > Group A can read/write existing files > Group B can read existing file > Group C can write existing file > Others have no access > > UFS does not allow this in a trivial fashion, because it has a finite > number of permission bits. Likewise I somewhat object to a model which > only has root/noroot as classes of API access, because it leads to the > wrong amount of priv granted. One way around it that I've been thinking about might work. Any comments? What if we make a way of allowing groups defined in /etc/groups to contain groups as well as uids? i.e. xrwxrwx--- fred.foo filename User fred and users on group foo can read and write to this file. could /etc/group foo contain: foo:*:1000:joe,fred,'group wheel' This would allow really useful generalisations of group access. i.e. joe and fred and anyone on group wheel can read and write this file. Comments? Joe -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970618151004.21788>