From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@closedmind.org To: 9fans@cse.psu.edu Subject: Re: [9fans] one reason ideas from Plan 9 didn't catch on MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-lrlzyyyvuwmshliogekixuiyew" Message-Id: <20011114144348.3542C199F2@mail.cse.psu.edu> Date: Wed, 14 Nov 2001 09:43:46 -0500 Topicbox-Message-UUID: 228fbeb2-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-lrlzyyyvuwmshliogekixuiyew Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I tried twice with XOS and Demos/MP. XOS was a traditional capability system, Demos a less traditional and more usable one. XOS was mine, Demos/MP from Los Alamos/Stanford. Demos is described in an old SOSP (in the 70's), XOS in a OSR in the 80's. We had the usual problem with persistence; garbage collecting the capabilities, revoking old capabilities, building tools to walk the arbitrary graphs that resulted and make some sense of them, ... Even something like tar turned into a major pain in the backside to build. When you gave someone a capability, you had to do a transitive closure of the access of that capability to figure out what you were giving away or restrict the capability to be intransitive. The result was a lot more copying. On the positive side, access control was nicer. Unfortunately, that was the only plus. I keep believing that capabilities are a good idea but the concept requires someone better than me to implement. --upas-lrlzyyyvuwmshliogekixuiyew Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Nov 14 05:05:50 EST 2001 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id A355119A9A; Wed, 14 Nov 2001 05:05:35 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id DF6A519A27 for <9fans@cse.psu.edu>; Wed, 14 Nov 2001 05:04:18 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 163wk6-0005aO-00 for 9fans@cse.psu.edu; Wed, 14 Nov 2001 09:54:02 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu From: Eyal Lotem Message-ID: <3bf1a2de@news.bezeqint.net> Organization: HyperRoll Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit References: <20011112192456.A4CD319ABF@mail.cse.psu.edu> Subject: Re: [9fans] one reason ideas from Plan 9 didn't catch on Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.7 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 14 Nov 2001 09:52:54 GMT anothy@cosym.net wrote: > no, not at all. i was talking strictly from the point of view of trying to > explain the systems to someone. the per-process namespaces are where > most people get stuck in their understanding. Per-process namespaces are very much like per-process capability pools, but allow processes to express requests they are not authorized to, as well as requiring a clumsy namespace-access interface. What advantages do you find to this, over pure capability systems? With capabilities, your requests are in terms of the capabilities you have (aka: Directly in terms of your authority), without having to 'name' them in a namespace. In other words, if you go through to process-grained security, with the more correct approach to security of visibility, and the terms of the requests themselves, why not go all the way, with pure capability systems? Getting rid of traditional file systems has other big pluses. I personally think that if Plan 9 implemented a pure capability system, and orthogonal persistency as early as it implemented its design, it could have caught on, and be a lot more secure/efficient. --upas-lrlzyyyvuwmshliogekixuiyew--