[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Recursive operations and authz

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Fri, 15 May 2015 06:04:04 +0200

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).

* If "d" is set on a path, you may delete any sub-node - sub-tree
  included and no further rights are required.

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

-- Stefan^2.
Received on 2015-05-15 06:04:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.