> -----Original Message-----
> From: Michael Wood [mailto:mwood@its.uct.ac.za]
> Sent: Sunday, April 27, 2003 5:43 AM
> To: Steven Brown
> Cc: 'Peter Burkholder'; dev@subversion.tigris.org
> Subject: Re: Permissions for repositories with Apache
>
>
> On Sat, Apr 26, 2003 at 11:06:15PM -0700, Steven Brown wrote:
> >
> > > <VirtualHost>
> > > ServerName paul.example.com
> > > User paul
> > > Group devgroup
> > > ...
> > > </VirtualHost>
> > > Each of these can have a DocumentRoot with the devlopers area.
> > >
> > > see http://httpd.apache.org/docs-2.0/mod/perchild.html
> >
> > I gave a perchild-compiled Apache a shot, but it currently seems
> > unusable due to stability issues and php being unable to
> work with it
> > safely (it locked up easily). If it worked, it'd be a
> better solution
> > than either of the ideas I could come up with, though. I
> poked around
> > on this lead to see if it could at least be used as a
> subersion-only
> > server, but it sounds like perchild still needs some work:
> > http://www.contactor.se/~dast/svn/archive-2002-08/0906.shtml
>
> If you just want multiple users on the machine to be able to
> set up and use private SVN repositories (e.g. in their home
> directories) then you could get them to use ra_local. If
> they need to access them remotely, you could get them to use
> ra_svn over SSH.
>
> If multiple users need to access the same repository, then it
> obviously gets more complicated. You haven't really
> described _what_ you want to be able to do. You've only
> described more or less _how_ you think you might do it.
I'm looking at it as a replacement for the CVS setup we have. We do
remote, multiuser CVS over ssh, but that's a pain to administer. It
takes root to get a repository setup securely, and then it takes root to
add shell users and change user permissions. In our environment, people
come and go often (students), and getting a root user to make a change
has taken up to a month in the past. Often, people will just create
world-writable CVS repositories in hidden directories on general access
servers to work around the administration problems, which is obviously
suboptimal.
Subversion's dav way of doing things sounds great to me. The webdav
support is really nice since everyone already has a webdav client, as is
being able to provide http links directly to files in the repository.
Also, you can grant read/write access without needing to mess with shell
users or give them shell access, use the same authentication methods
already in use for other web stuff, and ideally, do all this without
needing a root user to do it for you. Since non-owner users don't have
filesystem access to the repository, there're no worries of them
mangling the thing like people often love doing to CVS repositories
(many can't resist the temptation of moving directories in the
repository, and I'm sure the same people would find a way to break
subversion repositories).
So, that's why I've been trying to figure out how to get Apache's
permissions right. I think the dav way is the Right Way for subversion
as it has so many benefits, and if I could give control of a user's
repository to the user rather than to root, it'd solve the
administration problems, too. They could each run their own Apache, but
that'd be a new administration problem. It looks like there's still
work to be done on the Apache side for this to work nicely, as the
closest it comes to this is perchild vhosts, but it's not at a usable
state yet. For now, I've setup a special subversion-only Apache that
runs as user svn and I'll make some php scripts to allow for
administering its repositories.
The ideal solution would probably be adding setuid/gid functionality to
the prefork Apache when accessing ~user dirs and a more intelligent way
of managing spare server processes so it can pool by user/group and not
need to keep ones around for each inactive user, which would also get
rid of other permission problems with mod_mono/mod_php.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 28 03:00:20 2003