From owner-freebsd-hackers  Wed Jun 18 12:04:11 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA03945
          for hackers-outgoing; Wed, 18 Jun 1997 12:04:11 -0700 (PDT)
Received: from cypher.net (black@zen.pratt.edu [205.232.115.155])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA03935
          for <hackers@FreeBSD.ORG>; Wed, 18 Jun 1997 12:04:04 -0700 (PDT)
Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id PAA01930; Wed, 18 Jun 1997 15:05:17 -0400
Date: Wed, 18 Jun 1997 15:05:16 -0400 (EDT)
From: Ben Black <black@zen.cypher.net>
To: Don Yuniskis <dgy@rtd.com>
cc: Drew Derbyshire <ahd@kew.com>, hackers@FreeBSD.ORG
Subject: Re: granting auth to processes
In-Reply-To: <199706181316.GAA27714@seagull.rtd.com>
Message-ID: <Pine.LNX.3.91.970618150450.1835A-100000@zen.cypher.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

actually, this is a feature of any true capabilities-based system.  

On Wed, 18 Jun 1997, Don Yuniskis wrote:

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