From owner-freebsd-hackers Wed Jun 18 05:11:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA13159 for hackers-outgoing; Wed, 18 Jun 1997 05:11:00 -0700 (PDT) Received: from pandora.hh.kew.com (kendra.ne.highway1.com [24.128.53.73]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA13154 for ; Wed, 18 Jun 1997 05:10:56 -0700 (PDT) Received: from fantasy-factory.net.kew.com (uucp@fantasy-factory.net.kew.com [204.96.41.103]) by pandora.hh.kew.com (8.8.5/8.8.5) with ESMTP id IAA01622 for ; Wed, 18 Jun 1997 08:10:19 -0400 (EDT) Received: from kew-sonata.UUCP (uucp@localhost) by fantasy-factory.net.kew.com (8.8.5/8.8.5) with UUCP id IAA02043 for hackers@freebsd.org; Wed, 18 Jun 1997 08:10:16 -0400 (EDT) Received: by sonata.uucp.kew.com (UUPC/extended 1.12s); Tue, 17 Jun 1997 00:24:32 -0500 Message-ID: <33a61180.kew-sonata@sonata.uucp.kew.com> Date: Tue, 17 Jun 1997 00:24:32 -0500 From: "Drew Derbyshire" Organization: Kendra Electronic Wonderworks (PO Box 80144, Stoneham MA 02180) To: hackers@freebsd.org Subject: granting auth to processes 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. -- Internet: ahd@kew.com Voice: 617-279-9810 "OSI: Same day service in a nano-second world." - Van Jacobson