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

[Rob Meijer]

On Wed, December 30, 2009 00:38, David-Sarah Hopwood wrote:
> Rob Meijer wrote:
>> On Tue, December 29, 2009 05:20, Kevin Reid wrote:
>>
>>> The relevant aspect of "Save As" in this discussion is choosing a new
>>> filename/location for the document, not choosing the format.
>>
>> What might be interesting questions is, given the parallelisms to OOP,
>> should '[Save] As':
>>
>> * Include some sort of private/protected/public flag.
>
> No. The subjects that the file will be visible to, are the subjects that
> have access to the part of the namespace where it is saved. Adding any
> other kind of access control mechanism is redundant, and depending on the
> details of how that mechanism is specified, may introduce confused deputy
> attacks.

Agreed.

> "protected" only has meaning in the context of inheritance, which isn't
> involved here.
>
>> * Allow to choose between the private per pseudo persistent process
>>   namespace, the 'static' per application+uid namespace, the semi global
>> per
>>   uid namespace and the global multi user namespace?
>
> The namespace that the user sees in a Save As dialog, is the namespace
> that
> was given to the powerbox. It can include whatever the instantiator of the
> powerbox wants it to include, in any organization. That's a matter of
> policy.

If you look at it from an OO perspective (and forget for a moment about
multiple users to keep the model simpler) we could have a situation that
basically represents the following:

class PowerBox {
   private:
      static FilesystemNamespace *sProtectedPublicNamespace;
      ..
   public:
      static bool safeAs(File &thefile,
         FilesystemNamespace &staticnamespace,
         FilesystemNamespace &privatenamespace);
      ..
}

class Editor: public Application {
   private:
      static FilesystemNamespace *sStaticNamespace;
      FilesystemNamespace *mPrivateNamespace;
      bool safeAs(File &thefile) {
         PowerBox::letTheUserChooseAPlaceToPutTheFile(thefile,
            mStaticNamespace,mPrivateNamespace);
      }
      ..
    public:
       void run();
};

My view is that from a least authority viewpoint, the concept that
sProtectedPublicNamespace should be the only place to safe the file is a
bad one, given that in many cases placing it in sStaticNamespace would be
sufficient and constitute a less authoritative configuration, or in
mPrivateNamespace, what would constitute an even less authoritative
configuration. I agree SafeAs should allow the user to place the file into
the powerbox protected global namespace, given however that doing so when
one of the other two namespaces would do, in my view seems not to provide
the user with a facility to choose the least authority option.

>> * Only create a named reference to a facet/caretaker for the always
>>   'private' file?
>
> Yes, the obtained capability for the file might be a revocable proxy, for
> example. In the BrowserManager design I outlined, the membraned view of
> the filesystem can enforce any desired attenuation of the granted file
> capabilities.
>
>> In my view the ideal solution would allow safe-as to create a
>> facet/caretaker in the static,semi-global or global namespace,
>> defaulting
>> to a read read only facet /caretaker created in the semi-global
>> namespace.
>
> Whether the granted capability should be read-only depends on whether the
> user selected to view or edit the file. Alternatively, if there is an
> application framework controlling part of the app window (in particular
> the File menu), then it is possible to ensure that the file is only saved
> if, when, and where the user asks to save it.

The fact that a user could choose from application B to open a file for
editing that she SaveAs'ed from application A into the powerbox protected
global namespace as a read only attenuation seems to go against all logic.
If you see the concept of SafeAs as a way to place an attenuation to the
file into the shared (by proxy) namespace, than it should not be possible
to edit files that was not explicitly placed with unattenuated write
privileges into the namespace.

Rob