-1

I have a svn repository using authz to control the access. The structure looks like this:

├── branches
│   └── bob
├── tags
└── trunk
    └── A
        ├── B
        │   └── README.txt
        └── README.txt

Suppose the authz grants a user read access to directory A but not B, and it fails when I try to branch A:

[hidden]$ svn copy A ^/branches/bob/A1 -m 'Branching A to branches/bob/A1'
Adding copy of        A
svn: E220001: Commit failed (details follow):
svn: E220001: Access denied

The svnserve's log says

Authorization Failed recursive read /trunk/A

Why does svn has this restriction and is there a way to work around? Why doesn't it just ignore B when branching, just the same as doing a checkout?

If this turns out to be impossible, then what's the best workflow for svn with authz? It looks if branching is not allowed, the only way is everyone working on the trunk, but this is too stupid.

Kan Li
  • 8,557
  • 8
  • 53
  • 93
  • Probably because its is assumed, rightly IMO, that a valid branch would need to contain everything from the source even if the user attempting to branch does not have access to it because them presumably `A` would be broken without the contents of `B` and it would cause issued when attempting to merge `bob/A1` back to `/trunk/A`. – prodigitalson Mar 12 '15 at 02:57
  • @prodigitalson, IMO if it is a concern A would be broken without B, then svn checkout should be disallowed as well. – Kan Li Mar 12 '15 at 04:43
  • [Read the last sidebar block at the bottom of the page. It explains this.](http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html) – prodigitalson Mar 12 '15 at 14:19
  • @prodigitalson, I saw that many many times before I came up asking the question on SO. It doesn't answer my question IMO. It just says some directory will be skipped with partial read access when checkout; it doesn't mention why this behavior is allowed in checkout, but not allowed in branching. It doesn't address your concern either: given A would be broken without B, why checkout is allowed while branching is not allowed. – Kan Li Mar 12 '15 at 17:33
  • No not directly WRT my comment, it does say that it is specifically a limitation of how the process for authz works, ie. there is only a single auth check at the beginning against the top level dir one is attempting to check out. I assume this is contrasted with a typical branching command that would copy from remote to remote where everything can be checked as it goes, but im only guessing. It also warns specifically about implementing directory level access in a repository eariler in that same documentation. – prodigitalson Mar 12 '15 at 18:36
  • Overall it sound like if you want to do this you will need to reorganize your repo. For example potentially having a dir for `projectA/trunk` with an external to `projectB/trunkOrTag`. Obvisouly i site trunk but each one of these "projects" would have its own standard layout with tags/branches/trunk. – prodigitalson Mar 12 '15 at 18:39
  • @prodigitalson, I don't see any logical relationship between doing all things in one request and allowing skipping hidden directories. svn can still check recursive readability on `svn checkout` even it has to be done in one request. Also I don't think `svn copy` rejects it BECAUSE OF it has multiple requests. It is just a fact `svn checkout` only checks top level and `svn copy` does a recursive check. My question is why was that and is there a workaround if I don't want to re-organize my repository. – Kan Li Mar 12 '15 at 19:13

2 Answers2

1

SVN's initial authz implementation didn't check the whole subtree on copy, but added later to address this security hole.

So the conclusion is, SVN's authz was not designed well from beginning, sooner or later lots of hacky and dirty fixes got in, which eventually made your use case unsupported. IMHO a good implementation should just keep track of where a branch was copied from and check authz of the source as well.

I agree your use case is totally valid and Perforce supports path-based-authorization pretty well. Unfortunately you can't do it in svn. You can either switch to Perforce, or wait for them to improve authz.

John Smith
  • 76
  • 1
0

You have a deny permission on subnode B for that user, and deny permissions override read permissions.

When branching A, B cannot be skipped (it's inside A and, as far as SVN knows or cares, it's part of it). That's why you can't do it. It's actually a good thing that's it's preventing you as you don't normally want a branch that misses a folder from the source.

There shouldn't be a workaround for this, that behavior actually makes sense. To have the branch action succeed, you either need to:

  • move B outside of A
  • give the user access to A, and everything under it

I do understand there may be cases when this is frustrating, but if B is something that is not dependent on A, or if someone who works on A doesn't care about B or needs access to B - in such case B shouldn't really be inside A.

Lucius
  • 430
  • 4
  • 8
  • I don't agree with your logic. It is totally possible B is tightly related to A, and thus from logical and maintenance point of view, it is bad to move B out of A. On the other hand, B could be some optional, dynamically loaded library of A, so that users without access to B can still checkout/branching A and work on it, build it and test the main part of A. To sum up, it is a totally valid use case that A can work without B, but B is really a part of A, shared lots of things with A, such as code, build scripts, tests, thus a bad practice to split B out. – Kan Li Mar 27 '15 at 21:32
  • This is not my logic, but that of Subversion. You're trying to use Subversion. You found a use case scenario that doesn't work with branching. – Lucius Mar 28 '15 at 09:28
  • Then where is the official source saying this is the logic of svn? Where is the official source saying svn doesn't support branching of directory that contains authz protected subdirectory because "anything that is authz protected is not part of its parent so should not be inside the parent"? If this logic is really svn's official logic, why does svn supports authz for subdirectories in the first place? – Kan Li Mar 28 '15 at 13:18
  • I'm afraid you won't find that answer directly, it doesn't work that way. Have a look at http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html for some info about path based authorization in general. They basically don't recommend the approach, right from the start (that's the official docs). Your use case is just another example why it's not a good idea to do that. – Lucius Mar 28 '15 at 22:11