Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CF183E5C.1353C%anchela@adobe.com>
References: <CF183E5C.1353C%anchela@adobe.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Wed, 5 Feb 2014 14:00:45 -0500
Message-ID: 
 <CAOFYJNafSkrvyQ5F5SNiC0HAcW=_HWPVd3jBRY1Q2JB23+MKug@mail.gmail.com>
Subject: Re: Security of Move Operations
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Wed, Feb 5, 2014 at 1:15 PM, Angela Schreiber <anchela@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