From owner-freebsd-hackers  Wed Jun 18 08:51:14 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA23420
          for hackers-outgoing; Wed, 18 Jun 1997 08:51:14 -0700 (PDT)
Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23415
          for <hackers@FreeBSD.ORG>; Wed, 18 Jun 1997 08:51:12 -0700 (PDT)
Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121])
	by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id IAA05829
	for <hackers@FreeBSD.ORG>; Wed, 18 Jun 1997 08:50:51 -0700 (PDT)
Received: from localhost (narvi@localhost)
          by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP
	  id SAA20120; Wed, 18 Jun 1997 18:39:54 +0300 (EEST)
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
In-Reply-To: <19970618151004.21788@pavilion.net>
Message-ID: <Pine.BSF.3.96.970618181546.18537A-100000@haldjas.folklore.ee>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


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