Re: svn copy url1 url2 requires read access to repository root

C. Michael Pilato wrote:
> Stefan Küng wrote:
>> Hi,
>>
>> A user reported that TSVN would require read access to the repository
>> root for an 'svn cp trunk tags/versionX'. I've checked and the copy
>> fails if the user doesn't have read access to the repository root,
>> even with full write access to both /trunk and /tags.
>>
>> The mail thread is here:
>> http://groups.google.com/group/tortoisesvn-dev/browse_frm/thread/8e9d0c2154dc9e0a
>>
>>
>> Since the same happens with svn 1.4.x (not just with the latest trunk
>> build), I'm not sure if that's by design or not.
>
> This from libsvn_client.copy.c:repos_to_repos_copy():
>
> /* We have to open our session to the longest path common to all
> SRC_URLS and DST_URLS in the repository so we can do existence
> checks on all paths, and so we can operate on all paths in the
> case of a move. */
>
> Some of this is just the side-effect of using an editor drive to perform
> these copies/moves, as an editor must be rooted at the longest common
> directory of the things you wish to change. For moves, that means
> anchoring at the directory common to all move sources and targets. For
> copies, it means the directory common to just copy targets. I think for
> code simplicity we use the former anchor-point calculation for both
> copies and moves. The result is that copies can be anchored
> unnecessarily high in the tree, and that we do some unnecessarily editor
> traversing (opening extra directories till we get down to the one common
> to just the copy targets).
>
> In some ways, this could be considered a bug, but the obvious fix
> doesn't get us very far. In your use-case, anchoring lower in the tree
> for copies would mean only needing read access on '/tags', but as soon
> as somebody tries in one commit to do both 'cp /trunk /tags/1.1' and 'cp
> /trunk /branches/branch', they're right back to needing read access to
> the root of the repository. The *real* fix is either to make the authz
> checker smarter (like, "don't fuss about someone doing an innocuous
> request on DIR if they have read/write access to one of its
> descendents") or to get away from using svn_delta_editor_t for this
> operation.

Thanks for the explanation!
I just wanted to be sure that this is known, because I haven't found an
issue in the issuetracker for this (except some similar issues which are
marked closed or fixed).

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net