Date: Wed, 18 Jun 1997 08:05:56 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: joe@pavilion.net (Josef Karthauser) Cc: ahd@kew.com, hackers@FreeBSD.ORG Subject: Re: granting auth to processes Message-ID: <199706181505.IAA01834@seagull.rtd.com> In-Reply-To: <19970618151004.21788@pavilion.net> from Josef Karthauser at "Jun 18, 97 03:10:04 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In the words of the world-renowned author, Josef Karthauser: > 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. Write a perl script to expand group names from a /etc/groups.your_scheme file and recreate the /etc/groups file from this. It, however, doesn't solve the problem posed above... --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706181505.IAA01834>