Re: Setuid

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         dcchapman_at_acm.org
     Chapman Consulting -- San Jose, CA