On 7/22/2011 8:38 AM, Andy Canfield wrote:
Had what seems to be a bright idea. It is a bright idea for a
Subversion server on Linux or OS X; AFAIK this idea has no relevance
to Windows:
Take note of the user and group that Apache runs as. Call this
combination APACHE, meaning APACHE_USER and APACHE_GROUP.
Whatever mod_dav_svn does to any repository will be done by APACHE.
Whatever WebSVN does to any repository will be done by APACHE.
If I set the svnserve program to be owned by APACHE, and setuid and
setgid, then whatever svnserve does to any repository will also be
done by APACHE. Only root, or the APACHE user, can make this change to
the svnserve program binary.
If I set the svnadmin program to be owned by APACHE, and setuid and
setgid, then whatever svnadmin does to any repository will also be
done by APACHE.
If I set the svnlook program to be owned by APACHE, and setuid and
setgid, then whatever svnlook does to any repository will be done by
APACHE.
So the three access paths - http:, svn:, and direct - will all operate
using the same user and group.
You don't want to do this to any program, such as 'svn', which relies
on user authentication, since it needs to know the actual user that is
running the program. But any program which operates directly on the
repository can be set this way and that ensures that the repository is
always manipulated, at a low level, by the same user all the time.
So a post-installation setup would include:
* sudo bash
cd /usr/bin
chown APACHE_USER svnadmin svnlook svnserve
chgrp APACHE_GROUP svnadmin svnlook svnserve*
This idea also allows me to make the the respository itself accessable
only by APACHE. This ensures that the repository can only be
manipulated by Subversion code itself (or by root):
* sudo bash
mkdir /var/svn
chown APACHE_USER**/var/svn*
* chgrp APACHE_GROUP**/var/svn*
* chmod 0700 /var/svn*
If I also do this:
* sudo bash
rm /usr/bin/svnadmin*
then all repository creation would have to be done via something like
WebSVN, which I assume requires authentication.
How does that sound to you guys? Where are the flaws in this idea?
Thank you very much.
It prevents privately owned and managed repositories. Normally,
individual users can set up their own repositories for their own
(personal) projects or files. If you are planning to do this on a
server that you wish to lock down, then I see no reason why it would
cause problems, but if users can login and do other work on this
machine, you are constraining them.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
