You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2008/03/12 19:52:00 UTC
svn copy url1 url2 requires read access to repository root
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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: svn copy url1 url2 requires read access to repository root
Posted by Stefan Küng <to...@gmail.com>.
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
Re: svn copy url1 url2 requires read access to repository root
Posted by "C. Michael Pilato" <cm...@collab.net>.
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand