Hi Andreas, All,

On 22 June 2010 15:59, Andreas Maunz <andreas at maunz.de> wrote:

>> Discussion: It looks like both in (1) and (2) we would need an
>> additional state where a policy can exist for a short period of time
>> (how long?) without a corresponding resource in place.
>
> Only for a "virtual second". Exceptions during resource deletion must be
> caught and policy only deleted on succesful resource deletion.
> Of course, policy deletion could fail as well. In that case, resources would
> have to be restored. However, this might be impossible. Therefore, a
> workaround would be to first delete the policy instead of the resource. This
> would be safe, since, without a policy, access is blocked completely. Also,
> policies can be downloaded before deletion (in order to back them up for
> easy restore).

OK, I agree that reversing the order of the operations might be a
sensible approach, provided that the resource is not accessible when
no policy exists for this resource. That is to say:

-- Create: (1) resource, (2) policy;
-- Delete: (1) policy, (2) resource;

However, there are some issues that need further clarification in this
case as well:

1) At creation time, when no policy exists for a given resource and
nobody has access to this resource, how is the resource owner
differentiated, in order to allow him to create the corresponding
policy? It sounds like the ownership should be recorded elsewhere, not
in the policy itself? Or perhaps you meant inverting the order only at
deletion time?

2) When deletion is initiated and a given policy is removed, but the
associated (un)protected resource still exists for some time, what
would prevent a different user (not resource's owner) from creating
another policy for the same resource? Note that this opportunity could
be quite easy to exploit if the "attacker" happens to know the
resource URI and the resource web service is not responding for a
given time period, when the real owner attempts to delete the
resource.

3) Orphan (both resource and policy) prevention is still an issue,
regardless of the order of creation/deletion of policies and
resources. IMHO we need to define the procedures which would ensure
that (i) orphans would be highly unlikely to exist and if they do
emerge, that would be only for short periods of time (ii) eventual
orphans wouldn't survive for more than <some reasonable time interval
(e.g. 2 hours)>

Going back to the (unix) filesystem abstraction, we come to the
separate notions of permissions and ownership. I'm not sure whether
these two concepts can be easily and transparently merged in a single
policy. We might need to have separate means to describe ownership and
access permissions. As an example, imagine that user "vedrin", owner
of resource "test" declares that nobody (including himself) has access
to "test". In this case, the possible deadlock is avoided by the
separate ownership mechanism, which allows him to override this
restriction and access "test", since he is the owner of "test":

- - - - - - - - 8< - - - - - - - -
vedrin at eos ~ $ touch test
vedrin at eos ~ $ ls -al test
-rw-r--r--  1 vedrin  vedrin  0 Jun 22 16:44 test
vedrin at eos ~ $ chmod 000 test
vedrin at eos ~ $ ls -al test
----------  1 vedrin  vedrin  0 Jun 22 16:44 test
vedrin at eos ~ $ rm test
override ---------  vedrin/vedrin for test? y
vedrin at eos ~ $ ls -al test
ls: test: No such file or directory
- - - - - - - - 8< - - - - - - - -

It might be a sensible approach to think how to model this example in
our distributed RESTful services case.

Kind regards,
Vedrin