[cap-talk] Reducing the authority of a file browser in a capability OS.

[Rob Meijer]

On Tue, December 22, 2009 03:37, David-Sarah Hopwood wrote:
> Ben Kloosterman wrote:
>> the file explorer browser
>> will invoke via a file association the word processor it will then pass
>> in its own browse capability to the file to indicate the file ( this
>> being more secure than passing in the file name) . The word processor
>> itself will check if it has a higher level capability for the file.
>
> Why would the wordprocessor already have a more powerful capability?
>
> First, you don't appear to be distinguishing between applications and
> application instances. This is a common mistake that almost inevitably
> leads to systems that require excess authority.
>
> The user has only just indicated that they want *a new instance* of the
> wordprocessor to be able to edit the file. For either the instance or
> the application to *already* have a capability to do that is not needed,
> and would defeat the advantage of the powerbox pattern in maintaining
> POLA.

I know I have tried to make this point a few times before, but one reason
why the word-processor could already have a more powerful capability may
be that the word-processor created the file. If the system has some way to
restart the instance that created the file (a pseudo persistent process),
than this instance would have persistent access to the files it created.
I feel that in many instances this is preferable to the use of just a
powerbox pattern, given that the powerbox pattern requires file r/w
capabilities to be linked into a global user maintained global namespace.
As long as files are accessed and used by only one application, giving
pseudo persistent instances of this application their own private
namespace to place these files in, not cluttering the user maintained
namespace, seems to be much better than using the powerbox pattern.
Even if sharing is needed, the user may wish to only put a read capability
into the globally administered namespace, keeping the rw access restricted
to the application instance that created it.
For example if we have the word processor that created the file, and the
file is your resume. There seems no reason why you would for example want
to place the rw cap into the main shell (powerbox) its namespace. A ro cap
yes, as you may want to mail it, print it, etc, but no other application
should need to update the file, so the user would not need to link the
powerfull cap into the shell/powerbox its namespace.

In my view the powerbox can be greatly complimented, and possibly in some
cases even be replaced by a shell that allows starting petnamed pseudo
persistent instances of a program, and a system that gives each petnamed
pseudo persistent instance its own private namespace to link files under
that it creates. Add the posibility of delegation of sub trees (like
MinorFs does), and some form of attentuation and revocation facility, and
you could have an infrastructure where a user interface could allow one
application to create a revocable optionally attenuated file or directory
access capability to an other petnamed pseudo persistent instance of an
other program, or if needed to a non persistent program instance of an
other program.