From owner-freebsd-hackers Tue Sep 24 16:45: 6 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57E1537B401; Tue, 24 Sep 2002 16:45:04 -0700 (PDT) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BC2143E6E; Tue, 24 Sep 2002 16:44:58 -0700 (PDT) (envelope-from bts@fake.com) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g8ONimih004602; Tue, 24 Sep 2002 19:44:49 -0400 (EDT) Received: from this.is.fake.com ([24.162.238.30]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 24 Sep 2002 19:44:54 -0400 Received: by this.is.fake.com (Postfix, from userid 111) id D208CBA16; Tue, 24 Sep 2002 19:44:46 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: "Brian T. Schellenberger" To: "David P. Reese Jr." , Juli Mallett Subject: Re: Just a wild idea Date: Tue, 24 Sep 2002 19:44:46 -0400 User-Agent: KMail/1.4.2 Cc: hackers@freebsd.org References: <013f01c2320d$10ceff00$6401a8c0@dchristenson> <20020924080914.GA2870@tombstone.localnet.gomerbud.com> In-Reply-To: <20020924080914.GA2870@tombstone.localnet.gomerbud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209241944.46384.bts@babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You can get a somewhat similar effect right now (that is, root being not permitted to mess with your files) by using "cfs." Ok, true, root can still destroy your files by using the underlying "real" file system, but he can't view or manipulate them in their plaintext form. I must say that when I first installed cfs I was quite taken aback when, as root, I encountered this: i8k# ls /c/bts ls: bts: Operation not permitted i8k# Of course, it's not at all the same thing, really--root just has to 'su' to the ordinary user and then he gains privileges to the file, but you can never at one moment have the power of root *and* access to the files in the cfs file system. (Unless root is the one attached to them, of course.) On Tuesday 24 September 2002 04:09 am, David P. Reese Jr. wrote: | On Mon, 23 Sep, 2002, Lamont Granquist wrote: | >> Maybe just replace all suser(9) uses with MAC credential checks, | >> and install MAC_UNIX by default, which would be set up to behave | >> like ye olden UNIX... Who knows. | > | >Something like that sounds like a really good idea. I'd like to see | > this not only for binding to low ports but also, for example, to | > set the system time -- this would let you run ntpd as non-root. | > | >It'd be interesting to have a system one day where once you've gone | > past single user mode, root drops all its privs and acts just like | > a normal user account and daemon accounts only have special privs | > handed out to them in little chunks. | | This is starting to sound a bit too much like Plan9. Here is a very | short snippit on filesystem permissions from the document at: | http://plan9.bell-labs.com/wiki/plan9/KFS_file_system_configuration/i |ndex.html | | [snip] | There is no super-user; the closest equivalent is the person who | booted the terminal (generically called Eve; Adm owns the file | server). Most devices are owned by Eve, and the local kernel will let | Eve do most things commonly associated with a super-user (for | example, debug or kill processes she doesn't own). Eve's power does | not extend past the local machine, though, or even into the kfs file | system. The important difference is that the kfs file system is being | provided by a user process, which has its own permissions checking | separate from the kernel, and it does not care to let the hostowner | have special permissions directly. | [snip] -- Brian, the man from Babble-On . . . . bts@babbleon.org (personal) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message