On 15.05.2015 06:04, Stefan Fuhrmann wrote:
> Thank you to everyone who answered! From what I gathered
> so far is this:
>
> to (1) Requirering recursive or non-recursive write on a copy target
> should not make a difference to a typical authz setup with the
> current /trunk code. However, the provided paths *is* a change
> that should not be committed to /trunk as is.
>
> Reducing the required access rights to just non-recursive write
> to a copy target makes sense. So, 3rd party distributions may
> use the patch (e.g. to solve issues with wildcard use cases)
> if they are able to communicate the change in behavior to their
> users. Their risk is that new SVN releases will address this
> problem differently.
>
> to (2) Requirering write access to the target *and* its parent, i.e.
> today's behavior, should be kept for the time being. No compelling
> argument can be given at this time that makes checking only the
> parent the clearly better option
>
> to (3) Delete (hence, move) should continue to require recursive
> write access to the (source) path. Otherwise, we would change
> the intended behavior of existing setups.
>
> Further feedback:
>
> * Ideally, we would traverse the actuall sub-tree and check against
> the authz rules instead of using the authz recursion approximation.
> * mod_dav might perform that recursion by default. From talking
> to Ben, it seems though that is probably not the case.
>
> Idea how to solve the issue in SVN proper:
>
> * Introduce c(reate) and d(elete) access rights. The data structures
> on the authzperf branch have plenty of unused bit flags left.
>
> * If "c" is set on a path, you may create sub-nodes in it, e.g. by
> copying another node into it. No further rights are required on the
> target path (e.g. the whole tag including base folder is r/o).
Oops. Typically, "create" permission applies to the target, not its parent.
> * If "d" is set on a path, you may delete any sub-node - sub-tree
> included and no further rights are required.
As above; "delete" permission applies to the target. If we change that,
this would /really/ mean a change in philosophy.
Note that in a typical filesystem "move" and "delete" behave
differently: "move" requires non-recursive write access on the source
and target, whereas "delete" requires recursive write access on the
source. Our current authz implementation implicitly treats "move" as
"copy+delete".
> * Recursive write access to a path implies "c" and "d" are granted
> on that folder. This provides backward compat and allows authz
> users to only check for the new flags. The new authzperf data
> structs already comprise min/max sub-tree rights, making derived
> c&d rights available at virtually no extra costs. If there is no
> recursive
> write access on the parent (rare case), fall back to "write on parent,
> rec.write on target" check.
>
> * c and d do not imply any of the existing rights. While you probably
> want to set "r" with them, there is no reason that you have to. As a
> result, script users only need to know the path and have those new
> rights to manage branches & tags. No need to give them access to
> their contents.
The DAG of access rights should probably look like this, with each node
implying all its predecessors:
none
|
+-> traverse (lookup) ------+
| |
| +-> write contents ----|---------+
| | | |
+-> read contents -------+ | |
| | | |
| +--+-> read -+-> write
| | |
+-> read properties -----+ |
| | |
| +-> write properties ------------+
| |
+-> create ---------------------------+
| |
+-> delete ---------------------------+
Some systems treat create and delete permissions as separate from (not
implied by) write permission; many systems (notably Unix-like) do not
imply read permission by write permission. But we probably won't do that
because it would be a quite fundamental change in authz semantics, and
'write-only' probably doesn't make much sense in Subversion. On the
other hand ... create-only or delete-only are just as far-fetched, so
maybe we should change the graph such that they imply the read permission.
-- Brane
