Re: [9fans] capability-based design (Re: permissions idea)

[Richard <greon@best.com>]

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