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

Jeff Squyres wrote:
> 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
> -----

Can you give a reason why only god can read the test:/trunk/closed-directory ?
I perfectly understand why only he can write, but putting it "ro" is normal, IMHO.
So far I cannot think of a case like that...

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

What about having a working directory?

svn co -N --username human https://svn.example.com/svn/test-repo/
svn co --username human https://svn.example.com/svn/test-repo/trunk test-repo/trunk
svn co -N --username human https://svn.example.com/svn/test-repo/tags test-repo/tags
cd test-repo
svn cp trunk tags/tag1
svn commit --username human -m "make a tag"

Can this be done? Please try, as I just have this in my head, not tested.

I know that will be a PITA with big repos and it is a bit of typing :-(
It will actually not mage a good use, as tag1 and trunk will be different
from the beginnig.

But then, why do you have such permissions (see above question).

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

Hmm, very interesting... I haven't run into this (and I didn't bother testing
it - I trust you :-) but I don't like this behaviour as well. Which side
is better is also a difficult argument, but something has to be done.
A first step might be to print warning MSG on `svn co`:

WARNING: Directory bla-bla skipped. Access denied

or similar. The next step might be implementing a new command option, say
--fail-on-error that will abort the chekout on such warnings.

Any other comments?

Kalin.

-- 
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org