SVN per-path access rights

SVN allows configuring user access rights not only per-repository, as is currently supported by Virtualmin, but also very granularly per path inside repositories.

I'd be nice to be able to configure that in Virtualmin too. Though I'm not certain yet how to implement that in a useful manner... maybe allow manual entry of path names in the repository access screen.

Status: 
Active

Comments

I guess that could be implemented, although it would be a relatively complex additional to the current SVN UI.

Alternately you can manually edit the file etc/svn-access.conf under the domain's home directory, and add lines like :

[report:/relative/path]
user = rw
anotheruser = ro

Virtualmin won't touch any manual additions like this ..

I guess that could be implemented, although it would be a relatively complex additional to the current SVN UI.

Alternately you can manually edit the file etc/svn-access.conf under the domain's home directory, and add lines like :

[report:/relative/path]
user = rw
anotheruser = ro

Virtualmin won't touch any manual additions like this ..

Yeah, I can surely imagine that it'd be a complex thing. I've been using a software named "Visual SVN Server" under Windows, and that has a feature to edit per-path access rights in its GUI.

Manually editing the config file is of course an alternative.

So let's say, you might consider putting this on your "to do / nice to have" list, and should you ever feel bored, you could implement it. :)

Yeah, I'll add this to my TODO list .. no promises on how long it will be before it is done though :-)

No sweat, take your time. :)

I was just pondering to move hosting stuffs at my University working group to Virtualmin. For that, I'd even have to make a follow-up feature request: SVN user groups. We're using both that and per-path access rights there (see example below).

Oh, got an idea. Until VM maybe gets a real GUI to configure that stuff, can we have an editor text box to directly edit the appropriate svn-access.conf file in VM, instead of having to go SSH? That'd already be a big help!

And I have a lil cosmetic follow-up bug report:

In one domain, which I only use for SVN purposes, I moved the SVN Apache Location from /svn to /. Then the Validate Virtual Servers function complains about "missing SVN location". Which is partly correct, but confusing. :) Maybe avoid that error message, or show a "warning" instead, if the checker finds a location with "DAV svn" enabled but for a different path than expected.

[groups]
admin = user1
staff = user1,user2
researchers = user3,user4,user5
 
[/]
@admin = rw
@staff = rw
 
[sandbox:/]
* = rw
 
[project1:/]
@researchers = rw
 
[project2:/]
@researchers = r
 
[staff1:/directory1]
user1 = rw

Cool, I didn't even know there were groups ... I'll take a look at that too.

Thanks! I also edited my previous post to add two things... Didn't think you'd reply so quickly, so telling you in case you don't notice that. :)

Allowing direct editing of svn-access.conf would be an easy solution, but I am wary of allowing that as a mistake could break SVN access completely or even open un-intended anonymous access..

As for changing the /svn path to / , I'd recommend against that as all the code in the SVN plugin assumes that the path will be /svn . Instead, perhaps try using a redirect or mod_rewrite rule ..

I can understand your reluctance to allow editing... Maybe allow it for the master admin only? I mean, he really should know what he is doing. :)

As for mod_rewriting the / to /svn... I've tried doing that for the last hour now and am failing. It would seem that due to the way in which the SVN DAV handler works and fiddles with URIs, adding an "unexpected" /svn in front of it leads to errors.

I did this:

RewriteCond %{REQUEST_URI} !^/svn/.\*
RewriteRule ^/(.\*) /svn/$1 [PT]

I can use repository browsers (both web browser and Tortoise SVN) using that method, but when I try to check out a working copy, I get this:

10.0.9.6 - - [02/May/2011:23:09:04 +0200] "OPTIONS /uni/Pruefung/Nebenfach HTTP/1.1" 401 666 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "OPTIONS /uni/Pruefung/Nebenfach HTTP/1.1" 200 911 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /uni/Pruefung/Nebenfach HTTP/1.1" 207 568 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/vcc/default HTTP/1.1" 207 451 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/bln/275 HTTP/1.1" 207 464 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /uni/Pruefung/Nebenfach HTTP/1.1" 207 568 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/vcc/default HTTP/1.1" 207 451 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/bln/275 HTTP/1.1" 207 464 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /uni/Pruefung/Nebenfach HTTP/1.1" 207 568 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/vcc/default HTTP/1.1" 207 470 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/bc/275/Pruefung/Nebenfach HTTP/1.1" 207 574 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - - [02/May/2011:23:09:04 +0200] "OPTIONS /uni/Pruefung/Nebenfach HTTP/1.1" 401 666 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "OPTIONS /uni/Pruefung/Nebenfach HTTP/1.1" 200 911 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /uni/Pruefung/Nebenfach HTTP/1.1" 207 568 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /uni/Pruefung/Nebenfach HTTP/1.1" 207 568 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/vcc/default HTTP/1.1" 207 451 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/bln/275 HTTP/1.1" 207 464 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /uni/Pruefung/Nebenfach HTTP/1.1" 207 568 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/vcc/default HTTP/1.1" 207 451 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "PROPFIND /svn/uni/!svn/bln/275 HTTP/1.1" 207 464 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
10.0.9.6 - fz [02/May/2011:23:09:04 +0200] "REPORT /svn/uni/!svn/vcc/default HTTP/1.1" 500 430 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
 
[Mon May 02 23:09:04 2011] [error] [client 10.0.9.6] Could not parse 'src-path' URL.  [500, #190001]
[Mon May 02 23:09:04 2011] [error] [client 10.0.9.6] Unusable URI: it does not refer to this repository  [500, #190001]

At this point, the SVN client aborts with the "unusable URI" error message in the last log line.

So, I think it would be nice and better to be able to choose the (absence of a) URL sub-path for SVN within Virtualmin and not having to apply some complex and fail-prone rewriting. :)

Another note about the reluctance to allow people to edit the SVN config directly:

I can - already now through the "Services" section - directly edit a vserver's config for both Apache and BIND. And considering all the things I can break when doing that, how much worse can it possibly get when I can additionally break some SVN repositories? :-)

I guess that's true ..

I will add a proper UI for editing per-directory permissions in future.