Security of Move Operations

[Angela Schreiber <an...@adobe.com>]

hi

while discussion effect and possible solutions of OAK-920
michael duerig and myself come across a similar issue in the
move operation.

moving around a given node in the repository may result in the
situation that content previously not accessible to the editing
session becomes readable due to modified (inherited) permissions
in the target location.

while in the case of copy we considered it better to just copy
the readable items, this is not feasible in the case of a move
operation as it would basically remove that content from the
repository.

when discussing this in our weekly oak-meeting, tobi proposed
to change the permission evaluation for the move such that
modify-ac permission would be required on the source in order to
be able to complete the move.

this approach would however break backwards compatibility on how
permissions are enforced upon move.

wdyt?

kind regards
angela 

Re: Security of Move Operations

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Feb 5, 2014 at 1:15 PM, Angela Schreiber <an...@adobe.com> wrote:
> when discussing this in our weekly oak-meeting, tobi proposed
> to change the permission evaluation for the move such that
> modify-ac permission would be required on the source in order to
> be able to complete the move.
>
> this approach would however break backwards compatibility on how
> permissions are enforced upon move.

A possibly less intrusive alternative would be to require both read
and remove permissions on the whole subtree being moved. Even without
modify-ac, a user with full read/remove permissions could use other
content operations to achieve pretty much the same effect as a move.

BR,

Jukka Zitting