subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: Recursive operations and authz
Date Fri, 15 May 2015 09:15:22 GMT
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

> * 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:

     +-> 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

View raw message