[cap-talk] Value of 'copy on write' as attenuation mechanism.

[Rob Meijer]

On Wed, May 21, 2008 23:31, Toby Murray wrote:
> On Wed, 2008-05-21 at 11:05 +0200, Rob Meijer wrote:
>> While requesting feedback for my MinorFs project, one issue that came up
>> twice was the value of so called copy on write or COW mechanisms.
>>
>> Currently the design of MinorFs only provides for a generic attenuation
>> pattern that allows for deep, shallow and composed 'controled'
>> attenuation
>> of read and write. Combined with decomposition and composition, many
>> attenuations can be created, however facilities for COW are currently
>> not.
>>
>> Given that the main goal of MinorFs is to be a demonstration of
>> practical
>> use of sparse tokens in powerful discretionary Ocap related access
>> control
>> mechanisms, I am a bit troubled about the nature of COW. Is it an
>> essentially important form of attenuation, and if so, is it of value for
>> directory trees as such a core mechanism, or would providing COW for
>> files
>> combined with composition, be more in sync with the value of this
>> mechanism.
>
> Plash implements a limited form of COW. This COW feature has been used
> to good effect in the Plash package tools.
>
> The main use for COW, as I see it, is to facilitate POLA. An untrusted
> application can be given COW access to a subtree of the filesystem and
> run as normal, except the user can be assured it cannot cause lasting
> harm. Plus examining the differences between the original and any copies
> created provides a neat way of quantifying the damage the software could
> have done.
>
> COW provides "virtual" read-write access to a filesystem. In this sense,
> I think it is very useful for POLA. That might not be the question you
> asked though.


Yes, but given that COW is usefull for POLA, should we view COW as a
special but essential form of attenuation?

I am a bit confused as to 'real' storage for COW.
Lets look at two scenarios:

Scenario 1:

  * Alice delegates a directory to Bob granting full access to the dir.
  * Bob delegates a COW attenuation for this directory to Carrol

Scenario 2:

  * Alice delegates a read only attenuation of a directory to Bob.
  * Bob delegates a COW attenuation for this directory to Carrol

With normal attenuation, the space allocated can be seen as being bound to
the original owner of the original directory. However in the above
scenarios, the creation of the COW attenuation should in some way bind
potential storage for copies to the attenuation.

If not for scenario 2, you could say that the data allocation should be
bound to the original data owner. However, given that Alice delegates a
'read only' attenuation to Bob, allowing Bob or Carol to claim storage in
her name would seem strange.

Do you see my problem with fitting COW within the controled 'rw' based
attenuation patterns? I feel I not fully understand how COW should work
in a consistent and intuitive way for both the scenario's above.

Rob