[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights

From: Ben Reser <ben_at_reser.org>
Date: Fri, 22 Nov 2013 10:58:39 -0800

On 11/21/13 10:37 AM, sbremal_at_hotmail.com wrote:
> 1. Any user accessing Subversion has to be authenticated against the Unix password database. Works.
> 2. Before we hit the Subversion module I would like to authorize the user against the file system. Does not work.
>
> I have repositories laid out on the file system under '/usr/local/svn/' like this:
>
> drwxrwx--- 6 root backup 512 Feb 9 2012 backup
> drwxrwx--- 6 root common 512 Feb 9 2012 common
> drwxrwx--- 6 root news_alert 512 Jun 14 2012 news_alert
> ...
>
> Each repository's group is the collection of users who should be able to read and write it, plus the Apache's 'www' user. This works fine with 'svnserve', enforced by Unix.
>
> How could I convince Apache to check the directory access rights before it hits MOD_DAV_SVN? There are 2 flaws at the moment:
>
> 1. 'Require file-group' checks against '/usr/local/www/apache22/data/subversion/common' and not '/usr/local/svn/common'.
> 2. It also checks each path components of, for example, '/subversion/ppt/!svn/ver/48/trunk' and not only '/subversion/ppt/'.
>
> Any idea how to fix this? Any other approach to the problem?

You have hit upon a very old bug in Subversion. Specifically that Subversion
didn't disable httpd's translate_name functionality and so the httpd core is
converting the URL into a path on the file system under your DocumentRoot.

I can tell that you're using a version of Subversion before 1.8.3 or 1.7.13.
If you were using those versions or later you'd be running into a different
problem. Specifically that Subversion no longer maps requests to the file
system at all (the filename member of the request_rec is NULL). This caused
some problems with other modules that assumed that the filename was always set.

So in the soon to be released 1.8.5 and 1.7.14 we are filling in the filename
on the request_rec with svn:/path/to/repo/path/in/repo. For instance if you
swapped svn: with file:// you'd be able to use this as a URL to a svn command
on the server. For example your example above would show as
"svn:/usr/local/svn/ppt/trunk".

Neither of these help you since Require file-group needs to work by being able
to look at the group for the path filename is pointing at. In fact I went to
some effort to try and make it so that the filename should never map to a real
file on disk since there's really no correct path for us to map to. Mapping to
the same path (say the repository path) for every request can also be bad
mod_dir doesn't like it very much.

Where this leaves you is with two options:

1) Modify the translate_name hook in mod_dav_svn for 1.8.5 or 1.7.14 (which
will be out on Monday) to make it map to the repo path on every request.
You'll need to make sure you don't have any modules that don't like this (like
mod_dir as I mentioned above) enabled. Specifically all you need to do is find
the line in dav_svn__translate_name in subversion/mod_dav_svn/mod_davn.c
(relative to root of the directory the tarball extracts to) which looks like so:
  r->filename = apr_pstrcat(r->pool,
                            "svn:", fs_path, repos_path, SVN_VA_NULL);

Change that to just:
  r->filename = fs_path;

And the filename will be such that you should be able to use Require file-group.

2) Write your own replacement authz module for the functionality in Require
file-group that is specific to Subversion that calls dav_svn_split_uri() to
determine the path to the repository. The only problem with this is we don't
expose a way to retrieve the SVNParentPath in a public API and you need it to
calculate the full path to the repository. We do have a private function
dav_svn__get_fs_parent_path(), so you'd need to copy the declaration. We can
probably expose something better in the future.

Once you know the path of the repository checking the file group should be simple.
Received on 2013-11-22 21:17:59 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.