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

[David-Sarah Hopwood]

Rob Meijer wrote:
> On Wed, December 30, 2009 00:38, David-Sarah Hopwood wrote:
>> Rob Meijer wrote:
>>> * 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();
> };

There are no static variables in a capability system. The powerbox's
namespace is an instance variable of that powerbox.

In the above code, you have the editor choosing which namespace the
powerbox uses. That's not how I imagine it working at all. The powerbox
given to the app instance would be instantiated by some other policy-
enforcing code. It's a bad idea to let the untrusted app control the
namespace that is displayed by a trusted dialog; that wouldn't directly
increase the permissions of the app instance, but it might confuse the
user.

> My view is that from a least authority viewpoint, the concept that
> sProtectedPublicNamespace should be the only place to safe the file

[The word is "save". In fact "safe" and "save" both come from Latin
"salvus" via Old French "sauf", so the confusion is understandable for
a non-native English speaker.]

> is a bad one, given that in many cases placing it in sStaticNamespace would be
> sufficient and constitute a less authoritative configuration,

The user should be given the choice of where to put the file. There's no
good reason to artificially restrict where they put it, as long as they
have the necessary write capability in the relevant namespace. You seem
to be trying to enforce things that are not at all necessary to enforce
for security.

(Most apps in existing systems have a configuration option for the
*default* location in which to store files, i.e. the location that the
Save As dialog displays initially when a file is first saved. That's
configured in a different way for each app, which is a usability problem
that a capability system could easily fix, and probably would fix as a
side-effect of configuring it outside the app itself. I don't think
there's any reason to restrict the user from choosing any default
location they like, though.)

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

The mechanisms we're discussing here don't preclude passing any namespace
at all (which can be a composition or attenuation of other namespaces)
into the powerbox. As I keep saying, that's a policy issue, not a cap
system design issue.

>>> 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 a file is immutable, then it can't be modified by any app. If it was
only read-only, then it can be. I don't see the problem you're referring to.
If the user interface didn't give any indication that the file was to be
immutable, then the user has no basis on which to conclude that it can't
be changed.

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

That depends what the attenuation was intended to do. (It might only be
for revocation or logging, for example.)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091230/7b7ffa21/attachment.bin