From owner-freebsd-hackers  Wed Jun 18 06:13:45 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id GAA15583
          for hackers-outgoing; Wed, 18 Jun 1997 06:13:45 -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 GAA15574
          for <hackers@FreeBSD.ORG>; Wed, 18 Jun 1997 06:13:42 -0700 (PDT)
Received: (from dgy@localhost)
	by seagull.rtd.com (8.8.5/8.8.5) id GAA27714;
	Wed, 18 Jun 1997 06:16:13 -0700 (MST)
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199706181316.GAA27714@seagull.rtd.com>
Subject: Re: granting auth to processes
In-Reply-To: <33a61180.kew-sonata@sonata.uucp.kew.com> from Drew Derbyshire at "Jun 17, 97 00:24:32 am"
To: ahd@kew.com (Drew Derbyshire)
Date: Wed, 18 Jun 1997 06:16:12 -0700 (MST)
Cc: 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

> It's not so much the shared library vs. server which concerns me, but
> levels of access granted.  If every program didn't need full root access
> to change the effective user, it's not as big a problem.
> 
> 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.

Can you spell MULTICS?

--don