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
