Date: Wed, 18 Jun 1997 18:39:54 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Josef Karthauser <joe@pavilion.net> Cc: Drew Derbyshire <ahd@kew.com>, hackers@FreeBSD.ORG Subject: Re: granting auth to processes Message-ID: <Pine.BSF.3.96.970618181546.18537A-100000@haldjas.folklore.ee> In-Reply-To: <19970618151004.21788@pavilion.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Jun 1997, Josef Karthauser wrote: > 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' > Well some time ago (= this year, more than 2 months ago) an idea groped up when talking about ACL-s on the hackers was: Have something like permissionFS, fith directories as groups and files inside them as users belonging to that group. Don't treat subdirectories in any special ways (they are just groups like the parent), who can add new members to a given group depends purely on write permissions on that directory. As there is almost infinite (2^31? with only 1024 users on a system, each can have ~2M groups before running out) number of groups you have suddenly implemented ACLs without changing a single byte of existing filesystem code. The above case the permissions on the directory should be ownerx groupa rwxr-x--- and the file mode would be ownerx groupb rw-rw-r-- where: 1) People who must have read access belong to groupa 2) People who must have read and write access belong to both groupa and groupb Yes, there is the problem with ownerx creating a hard link to it in another directory. Sander PS. I did not think this out. There is no love, no good, no happiness and no future - all these are just illusions. > 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?Pine.BSF.3.96.970618181546.18537A-100000>