On 13.05.2015 08:21, Stefan Fuhrmann wrote:
> I have 3 questions:
>
> (1) Is there something fundamentally wrong with this
> approach, e.g. braking major use-cases?
It will certainly change how some authz files work, but that can be
fixed. The net effect is be that users users would be able to copy or
move to a location from which they are note able to move away from or
delete afterwards, whereas currently they wouldn't be able to perform
the copy or move in the first place.
This reduces authz restrictions for the same authz configuration, but
since it's a server-side change and easily compensated for in the authz
config if the current behaviour is what the admin intended, I don't see
a real problem.
> (2) Should we require write access to target and target's
> parent folder (as done by the patch) or just to the target's
> parent folder?
This is a tricky question. Since there are valid arguments for both
behaviours, I vote for consistency: we currently require write to
target+parent, so let's keep it that way.
> (3) Should we (optionally?) reduce the access rights reqs
> for DELETE similarly such that no recursive write access
> is needed? That seems risky but would be symmetrical
> to creating copies with r/o or n/a sub-paths. MOVE would
> be updated accordingly (always the same reqs as a COPY
> + DELETE).
Unlike the answer to your question (1) this is a definite no. If we do
this, admins will have no way to restore current behaviour.
The answer might be different it we had an explicit 'delete' permission;
but we don't, it's implied by the 'write' permission so it has to remain
recursive.
-- Brane
Received on 2015-05-13 09:14:37 CEST