Re: mod_dav_svn + automatic per-directory user authorization
This might be exactly what's needed if you're, say, teaching a programming class where you want students to learn to use Subversion for version control of their projects. You don't want students to be able to mess with each others' code, and you probably don't want to retain their data forever once the class is over. I don't know if that's the original poster's situation, but that's what it immediately reminded me of. Thanks for a great example. My situation is quite similar to what you describe actually, but consider _lots_ of students. This can be also compared to some projects hosting service with multiple projects hosted (and a repository for each), and multiple users accessing each project repository. I believe multiple separate repositories work much faster in this case than a single one, also there's absolutely no need for a single versions set - every student or project _must_ know nothing about others. The only problem as I wrote before is automatic authorization - the user A with the password B tries to access the repository C, and the information whether or not A is allowed to access C (and whether A's password is valid) is stored in MySQL due to the size of the users database and because of interoperability with other subsystems like external user management. I need to implement such authorization with as little coding as possible, optimally simply by using standard httpd/mod_dav_svn configuration options, so semi-standard extra modules and probably simple scripts.
Re: mod_dav_svn + automatic per-directory user authorization
On Sat, Feb 12, 2011 at 2:25 PM, David Chapman dcchap...@acm.org wrote: Repositories are meant to preserve data, implying they are relatively long-lived. Are you suggesting that repositories will be deleted all the time? If so, a master server-based configuration like httpd may not be appropriate for you at all. You may need something more dynamic like svnserve via inetd (look for that subject heading in the Subversion book). I don't have any experience with that, however. Your access requirements (many small repositories, many users, fine-grained path-based authorization) don't sound like what Subversion is designed for. It may not be an appropriate tool for you. This might be exactly what's needed if you're, say, teaching a programming class where you want students to learn to use Subversion for version control of their projects. You don't want students to be able to mess with each others' code, and you probably don't want to retain their data forever once the class is over. I don't know if that's the original poster's situation, but that's what it immediately reminded me of. -- David Brodbeck System Administrator, Linguistics University of Washington
mod_dav_svn + automatic per-directory user authorization
The problem: 1) there's a directory on the server containing multiple svn repositories roots, say /var/svn, with /var/svn/a, /var/svn/b, etc. being repository roots 2) these repositories are accessed via HTTP, handled by Apache2 + mod_dav_svn 3) there's a MySQL user-password database we need to use to authenticate access to those repositories 4) at last the problematic place itself: the repository /var/svn/$username must be accessible (both read and write) only to those who authenticated themselves as $username with a valid password from the MySQL database Currently i've stuck with two solutions (both incomplete) from tons of manuals and how-tos: a) AuthzSVNAccessFile could be a key to such an automatic repository - user binding, but updating the access rights file on changes to MySQL database looks no way elegant, and will probably become a bottleneck with growing users database b) mod_auth_mysql (whatever one) makes it possible to transparently use the users database in Apache config, but still I'm unable to find a way to automatically Require user $username for a given repository /var/svn/$username. Please reply, if someone has an experience with such a configuration, any ideas/thoughts are welcome.
Re: mod_dav_svn + automatic per-directory user authorization
On 2/12/2011 8:34 AM, m irya wrote:
The problem:
1) there's a directory on the server containing multiple svn
repositories roots, say /var/svn, with /var/svn/a, /var/svn/b, etc.
being repository roots
2) these repositories are accessed via HTTP, handled by Apache2 + mod_dav_svn
3) there's a MySQL user-password database we need to use to
authenticate access to those repositories
4) at last the problematic place itself: the repository
/var/svn/$username must be accessible (both read and write) only to
those who authenticated themselves as $username with a valid
password from the MySQL database
Currently i've stuck with two solutions (both incomplete) from tons of
manuals and how-tos:
a) AuthzSVNAccessFile could be a key to such an automatic repository
- user binding, but updating the access rights file on changes to
MySQL database looks no way elegant, and will probably become a
bottleneck with growing users database
b) mod_auth_mysql (whatever one) makes it possible to transparently
use the users database in Apache config, but still I'm unable to find
a way to automatically Require user $username for a given repository
/var/svn/$username.
Please reply, if someone has an experience with such a configuration,
any ideas/thoughts are welcome.
I'm not sure I understand the problem. Except for not using mysql to
access passwords, this is what I have now, and it works fine (with one
very important caveat: see below). Here is part of my httpd.conf file:
VirtualHost 1.2.3.4:80
ServerName repos1.mydomain.com
ServerAlias mydomain.com
ServerAdmin ad...@mydomain.com
# just a placeholder:
DocumentRoot /home/user1
Location /user1
DAV svn
SVNPath /home/user1
AuthType Basic
AuthName Subversion repository
AuthUserFile /etc/passwd.user1
Require valid-user
AuthzSVNAccessFile /home/user1/conf/access.conf
/Location
Directory /home/user1
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
/Directory
# log user1 operations separately from other users' operations
CustomLog /var/log/httpd/svn_logfile %t %u user1 %{SVN-ACTION}e
env=SVN-ACTION
/VirtualHost
and the file /home/user1/conf/access.conf has:
[user1:/]
user1 = rw
There's been some name changing here, so this configuration has not been
tested in this precise form :-) but you get the idea. Every repository
has its own VirtualHost and its own access file; unless you have the
password for the one user in the repository, you can't read any of it.
You don't need to have VirtualHost entries for each repository; I host
multiple domains on a single machine and so I chose to have a different
host name (e.g. user1.mydomain.com) for every repository. This also
allows me to have user-specific access logging with CustomLog. You
could simply have a set of Location entries at the top level of the
httpd.conf file.
Note: VirtualHost with name-based hosts is incompatible with SSL
access (https://). I have a small number of repositories (and some
spare IP addresses), so in theory I could use network adapter aliasing
with ifconfig, but I haven't got that far yet. Last time I tried
certificates I made a mess, and I spent too much time last month working
on computers anyway.
Here's the big caveat: whenever a repository is added or removed (in
your case, every time a user is added or removed), httpd must be
restarted because a Location entry must be added or removed. This
could be the big bottleneck, and if you use httpd to serve your
repositories, it's unavoidable. I know that some publicly accessible
Subversion hosting services (e.g. unfuddle.com) use http:// access, but
I don't know how they manage adding or removing users (unfuddle.com
advertises up and running in as little as one minute).
So you need some method of getting the username and password from mysql
to httpd (replacing AuthType and AuthUserFile), but otherwise it's
pretty straightforward.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Re: mod_dav_svn + automatic per-directory user authorization
Yep, i could manage to get to such configuration, but here's when it comes to the real difference with your setup: we need to manage a huge and frequently changing user database, with each user having a small repository. Here's the big caveat: whenever a repository is added or removed (in your case, every time a user is added or removed), httpd must be restarted because a Location entry must be added or removed. And that's what i'm trying to solve: the users database is not so tiny, so 1) we can't afford restarting httpd on every user added or removed 2) we can't afford duplicating the rules in authz svn access file, i guess it may be handled inefficiently when it contains too much records (at least much less efficiently than just requesting the authorization from MySQL). I'll try to describe it the other way, one abstraction level upper: 1) the user goes to http://somehost/repo/$something 2) authenticates him/herself as $username:$password (suppose Basic auth, just will change it to https later) 3) Apache checks the credentials against MySQL database (mod_auth_mysql?) 4) If everything is ok, the user gets a WebDAV access to /var/repo/$username/$something (regardless of the method, read or write) The database may change frequently, adding the user will mean `svnadmin create /var/repo/$username`, removing will mean `rm -rf /var/repo/$username`, but i prefer that nothing is done beyond that, especially no httpd configuration changes and restart, all information is stored in DB and nothing else should be changed.
Re: mod_dav_svn + automatic per-directory user authorization
On 2/12/2011 1:11 PM, m irya wrote: Yep, i could manage to get to such configuration, but here's when it comes to the real difference with your setup: we need to manage a huge and frequently changing user database, with each user having a small repository. Here's the big caveat: whenever a repository is added or removed (in your case, every time a user is added or removed), httpd must be restarted because aLocation entry must be added or removed. And that's what i'm trying to solve: the users database is not so tiny, so 1) we can't afford restarting httpd on every user added or removed 2) we can't afford duplicating the rules in authz svn access file, i guess it may be handled inefficiently when it contains too much records (at least much less efficiently than just requesting the authorization from MySQL). SVNParentPath will allow you to store multiple repositories under a single master directory, and the Subversion book says this is a good way to avoid restarting httpd when adding new repositories. I'd be very leery of _removing_ repositories without restarting httpd, however - what would happen if a transaction were being processed at the moment you deleted the repository directory? You're expecting mod_dav_svn not to crash in a way that brings down the server. I'll try to describe it the other way, one abstraction level upper: 1) the user goes to http://somehost/repo/$something 2) authenticates him/herself as $username:$password (suppose Basic auth, just will change it to https later) 3) Apache checks the credentials against MySQL database (mod_auth_mysql?) 4) If everything is ok, the user gets a WebDAV access to /var/repo/$username/$something (regardless of the method, read or write) The database may change frequently, adding the user will mean `svnadmin create /var/repo/$username`, removing will mean `rm -rf /var/repo/$username`, but i prefer that nothing is done beyond that, especially no httpd configuration changes and restart, all information is stored in DB and nothing else should be changed. Repositories are meant to preserve data, implying they are relatively long-lived. Are you suggesting that repositories will be deleted all the time? If so, a master server-based configuration like httpd may not be appropriate for you at all. You may need something more dynamic like svnserve via inetd (look for that subject heading in the Subversion book). I don't have any experience with that, however. Your access requirements (many small repositories, many users, fine-grained path-based authorization) don't sound like what Subversion is designed for. It may not be an appropriate tool for you. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
