"svn cp" has different permissions semantics than "svn co"

Greetings.

I have found some unexpected behavior (at least from our perspective),
and we're not sure if it's a bug or a deliberate design/implementation
decision -- I supposed one could argue it either way. So I bring the
issue up to the SVN community to ask for some advice...

The issue is that if a restricted directory (via authz) exists in a
tree where an unprivileged user tries to copy that tree, the user will
get amorphous errors and finally fail.

Here's an example (this is with SVN client v1.2.3, server v1.1.4):

-----
svn co --username god https://svn.example.com/svn/test-repo/trunk
god-test-repo
cd god-rest-repo
mkdir open-directory closed-directory
touch open-directory/file
touch closed-directory/file
svn add open-directory
svn add closed-directory
svn ci --username god -m "commit it all"
-----

Now go edit the corresponding authz file and set the following
permissions:

-----
[test:/]
* = rw

[test:/trunk/closed-directory]
* =
god = rw
-----

Now try to checkout as a different user (i.e., one that does not have
permissions in /trunk/closed-directory):

-----
svn co --username human https://svn.example.com/svn/test-repo/trunk
human-test-repo
-----

That works with no problem -- the "closed-directory" directory is
silently omitted. However, the problem is if the "human" user tries
to copy the /trunk into, say, /tags:

-----
svn cp --username human -m "make a tag" \
        https://svn.example.com/svn/test-repo/trunk \
        https://svn.example.com/svn/test-repo/tags/tag1
Authentication realm: <https://svn.example.com:443> Test Access
Password for 'human':
--> enter the human's password, even though it should already be cached
Authentication realm: <https://svn.example.com:443> Test Access
Username:
--> enter human
Password for 'human':
--> enter human's password
Authentication realm: <https://svn.example.com:443> Test Access
Username:
--> enter human
Password for 'human':
--> enter human's password
svn: COPY of tags/tag1: authorization failed (https://svn.example.com)
svn: Your commit message was left in a temporary file:
svn: 'svn-commit.tmp'
-----

In one sense, you can see why the copy failed -- the "human" user was
not able to read the full source tree (i.e., human couldn't read
closed-directory).

But on the other hand, human *was* able to successfully check out the
trunk without error. So why shouldn't human be able to cp as well?

The flip side of that argument, though, is that if any user (including
a restricted user such as "human") is allowed to cp any tree regardless
of permissions, then the results of that copy are dependent on who made
the copy.

But then again, this is just like normal unix filesystem permissions --
the contents of a "cp -rf" are dependent on who executed the command.

... this argument goes on ad nauseam. Each side has valid points.

This difference in permission semantics confused us for a while before
we figured out what was going on. It actually is somewhat painful --
it means that we cannot have restricted-access directories within our
source tree, because then *only* developers with full access to the
entire /trunk can make branches (we're in the habit of making lots of
developer-private temporary branches when someone needs to go off and
break the trunk for a while; they merge back up to the trunk when
they're done).

More specifically, it would be fine (from our perspective) if the
results of a "cp" are dependent upon the permissions of the user who
executed it. To ground this in the concrete example from above: it
would be fine for human to have a copy of the trunk in /tags that does
not have the closed-directory.

Comments?

-- 
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org