From owner-freebsd-hackers  Wed Jun 18 08:03:26 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA21059
          for hackers-outgoing; Wed, 18 Jun 1997 08:03:26 -0700 (PDT)
Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21052
          for <hackers@FreeBSD.ORG>; Wed, 18 Jun 1997 08:03:23 -0700 (PDT)
Received: (from dgy@localhost)
	by seagull.rtd.com (8.8.5/8.8.5) id IAA01834;
	Wed, 18 Jun 1997 08:05:56 -0700 (MST)
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199706181505.IAA01834@seagull.rtd.com>
Subject: Re: granting auth to processes
In-Reply-To: <19970618151004.21788@pavilion.net> from Josef Karthauser at "Jun 18, 97 03:10:04 pm"
To: joe@pavilion.net (Josef Karthauser)
Date: Wed, 18 Jun 1997 08:05:56 -0700 (MST)
Cc: ahd@kew.com, hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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