2

There seems to be a path inheritance issue which is boggling me over access restrictions. For instance, if I grant rw access one group/user, and wish to restrict it some /../../secret to none, it promptly spits in my face.

Here is an example of what I'm trying to achieve in dav_svn.authz

[groups]
grp_W = a, b, c, g
grp_X = a, d, f, e
grp_Y = a, e,

[/]
* = 
@grp_Y = rw

[somerepo1:/projectPot]
@grp_W = rw

[somerepo2:/projectKettle]
@grp_X = rw

What is expected: grp_Y has rw access to all repositories, while grp_W and grp_X only have access to their respective repositories.

What occurs: grp_Y has access to all repositories, while grp_W and grp_X have access to nothing

If I flip the access ordering where I give everyone access and restrict it in each repository, it promply ignores the invalidation rule (stripping of rights) and gives everyone the access granted at the root level.

Forgoing groups, it performs the same with user specific provisions; even fully defined such as:

[/]
a = rw
b = 
c = 
d = 
e =
f = 
g = rw

[somerepo1:/projectPot]
a = rw
b = rw
c = rw
d =
e = rw
f =
g = rw

[somerepo2:/projectKettle]
a = rw
b
c
d = rw
e = rw
f = rw
g

Which yields the exact same result. According to the documentation I'm following all protocols so this is insane.

Running on Apache2 with dav_svn

StudentKen
  • 207
  • 1
  • 3
  • 10

3 Answers3

3

After a bunch of headaches, I let this idle with * = rw at SVNParentPath level. Coming back to it, I suddenly had a stroke of obvious hit me; the read order was the issue.

Firstly, my naming conventions were flat out wrong as it should be [<repo_name>:<path-in-repo>]

The main issue is the authz file expects an order of 'specificity' where the first read rule, or available match is applied. In my case, everything would match with the root and it would be one-and-done. thus by reversing my example ordering:

[groups]
grp_W = a, b, c, g
grp_X = a, d, f, e
grp_Y = a, e,

[ProjectPot:/]
@grp_W = rw

[ProjectKettle:/]
@grp_X = rw

[/]
* = 
@grp_Y = rw

would make it accepted and perform as behaved. This is NOT DOCUMENTED and in my opinion is a serious snafu over something utterly trivial.

StudentKen
  • 207
  • 1
  • 3
  • 10
0

I ran into the same thing not long ago and also failed to come up with a solution. Some cheap apache alias rules and or svn:external definitions may help but if it gets moderately complicated I don't think you can do it today. WANdisco has had a number of requests for this feature and it may get enough momentum to merit an enhanced authz with non-inherited access and regular expression support.

vinnyjames
  • 373
  • 1
  • 7
  • Dav_svn authz has been around since 2001, I can't believe this hasn't been resolved. Is there a package for apache that performs the same functionality? – StudentKen Jan 13 '11 at 12:02
0

You have to give full url to access the repository that have permission otherwise need to give read permission like this.

[groups]
grp_W = a, b, c, g
grp_X = a, d, f, e
grp_Y = a, e,

[/]
* = 
@grp_Y = rw
@grp_w = r
@grp_x = r
[somerepo1:/projectPot]
@grp_W = rw

[somerepo2:/projectKettle]
@grp_X = rw
NCA
  • 1
  • 1