From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] capability-based design (Re: permissions idea) In-Reply-To: <20011004191609.B7DB9199B5@mail.cse.psu.edu> References: <20011004191609.B7DB9199B5@mail.cse.psu.edu> From: Richard Message-Id: Date: Thu, 4 Oct 2001 13:27:23 -0700 Topicbox-Message-UUID: fd8b377c-eac9-11e9-9e20-41e7f4b1d025 rog@vitanuova.com writes: >> the app must asks permission (from the OS, which >> then might ask the user) before doing anything significant to the user's >> software environment. > >surely that assumes that the user wouldn't just automatically accept >any reasonable-sounding request to open a file (i know i would, >especially if i had several hundred per day). the user does not have to do it explicitly, he can have programs dispense permission on his behalf. the user can write these programs or they can be provided by whoever provides his software. so for example, the program that installs your email client would ask you for permission to create a file to archive mail in. actually it would call a file-creation primitive, which would ask you. the creation primitive would return a file descriptor to the installer, which could do whatever it wanted with the descriptor. a sensible thing to do would be to give it to the email client "factory". the email client factory is the program that can start instances of the actual email client. (think of an app's icon on a Windows desktop.) the email client factory would in turn give the file descriptor to the email clients processes it creates, so that the process need not bother the user with mention of the archive file. so, after installation, the software environment need never ask the user for permission to open the archive file. now on Plan 9 and Unix, open file descriptors cannot survive a reboot. a capa OS would need to provide for their survival somehow. eg, EROS and KeyKOS (proprietary OS mired in intellectual-property hell which is the main inspiration for EROS) have persistent processes that can survive reboot. (and their data of course survives with them.) the reason they made that design decision is that most of the opportunity for inadvertently creating security holes in a capa software environment occurs during setting things up and starting things up. I have been talking about file descriptors, but I really mean capabilities. an open file descriptor is very much like a capability that cannot be forged. an unforgable pointer to an object (thing with state and methods) is also essentially a capability, if you prefer OO thinking over 9ish file thinking. >capabilities (and ACLs) seem to me like they'd be a maintenance >nightmare. i can barely remember to chmod my personal files 600... again, a software environment suited to a user needs to ask the user for permission only when the user wants to do things differently from what was decided by whoever provided his software. eg, nothing in a capability-based software environment is inconsistent with a docile user who knows nothing about security where all security policies have been decided by the "vendor" or (Linux terminology) "distribution maintainer".