Questions[mod-dav-svn](server)

I have the following setup:

<Location /repos>
  DAV svn
  SVNParentPath /home/svn/repos
  AuthType Basic
  AuthName "SVN"
  AuthUserFile /home/svn/.htpasswd
  Order deny,allow
  Require valid-user
</Location>

Users can access their svn repositories like this:

http://theserver/repos/therepository

If you try to access the following address in the browser...

http://theserver/repos

You get a 403 Forbidden. I'd like to make it so that users can browse that folder and see the repositories.

I thought adding the following

<Directory /home/svn/repos>
  Options +FollowSymlinks +Indexes
  AllowOverride all
</Directory>

Would do it, but I still get 403 Forbidden...

Any thoughts?

Apologies in advance for the possibily-incorrect terminology and probably-naïve question!

Is the Apache module mod_dav_svn linked to the SVN binaries in one way or another?

I am doing the initial research for an upgrade to our current 1.4.x SVN installation, and I am wondering whether compiling the latest 1.6.x version means we also need to compile a new version of mod_dav_svn, or does the mod_dav_svn just act as a proxy and invoke the svn binaries itself, meaning that we could swap in the new version without needing to do anything to the Apache configuration.

I have an apache2 server with active mod-wsgi, but I can't get the environment variable PYTHON_EGG_CACHE.
Here the important lines out of my virtualhost.conf:

    DAV svn
    SVNParentPath /var/svn
    SVNListParentPath Off

    WSGIProcessGroup sites
    WSGIApplicationGroup %{GLOBAL}
    SetEnv PYTHON_EGG_CACHE /var/trac/eggs

    AuthType Basic
    AuthName "Restricted SVN"
    AuthBasicProvider wsgi
    WSGIAuthUserScript /var/trac/cgi-bin/acctmgr_auth.wsgi
    Require valid-user

And here the acctmgr_auth.wsgi:

import os, sys
os.environ['PYTHON_EGG_CACHE'] = PYTHON_EGG_CACHE

from trac.env import open_environment, Environment

acct_mgr = None

def check_password(environ, user, password):
    global acct_mgr

    # Try loading the env from the global cache, addit it if needed
    environ['PYTHON_EGG_CACHE']
    env = open_environment(environ['trac.env_path'], use_cache=True)

    if acct_mgr is None:
        from acct_mgr.api import AccountManager
        acct_mgr = AccountManager

    if acct_mgr(env).check_password(user, password):
        return True
    else:
        return False

def groups_for_user(environ, user):
    return ['']

The single environ['PYTHON_EGG_CACHE'] is just a test, but I get a

KeyError: 'PYTHON_EGG_CACHE'

.

I also tried following, but I get the same error as above:

        RewriteCond ${lowercase:%{REQUEST_URI}} ^/svn/([^/]+)
        RewriteRule . - [E=trac.svn_path:/var/trac/envs/%1]

What is wrong?

Thanks for any advices.

EDIT: After some resarch I think I found the problem. The mod_dav is configured for the location /svn and it processes the request immediately, so the rewritecond and rewriterule will be ignored.
Is there any possibility to set environment variables with mod_dav?

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

I've set up a dedicated Subversion server with Apache and mod_dav_svn on Ubuntu 9.10 Server, and I've got everything working fine at this point. However, I noticed that when it comes to assigning the right file permissions to the repository directory, most tutorials telll you to do something like this:

sudo chown -R www-data:www-data /svn/myrepo # make www-data the owner of the repo so Apache
                                            # can write to it
sudo chmod -R g+ws /svn/myrepo  # Give the www-data group write access as well, and enable
                                # setgid so that new directories have that group

Now, I did it a little differently. I created a new subversion group, and made that the owner of the repository, then added myself and www-data to that group, the reasoning being that this way I can edit the configuration files in /svn/myrepo/conf and the hook scripts in /svn/myrepo/hooks, and it also keeps Apache and Subversion a bit more separate from each other. I've seen other tutorials recommend something similar, but then tell you to do this:

sudo chwown -R www-data:subversion /svn/myrepo
sudo chmod -R g+ws /svn/myrepo

These same tutorials imply that you are creating the subversion group specifically to keep Subversion and Apache mostly separate from each other, so why do they turn around and make www-data the owner of the files? Is there any good reason to make www-data the owner of the repository files at all? Why not just make root the owner? It seems like keeping www-data as the owner of the repository unnecessarily ties Subversion "too much" to Apache. Is there any good reason to make the owner www-data instead of root, as long as the group is still subversion?