On Thu, Jul 21, 2011 at 11:05 AM, Daniel Neuberger <daniel.neuber...@gmail.com> wrote: > On Thu, Jul 21, 2011 at 10:51 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: >> Stop *RIGHT* there. Go grab the Subverson 1.6.x from the RHEL updates. >> Do not pass go, do not collect $200 until you do this sitewide. There >> are significant security and performance improvements, well worth the >> update pain. > Okay, we plan to do that asap, but it will take at least a little > time. In the meantime, there's no reason to believe that's causing my > problem though, right? > >> That said, putting "suid" bits on svnserve is just begging for >> confusing pain in a configuration that no one has been using. Can you >> not use the svn+ssh shared account access, with SSH keys restricted to >> svnserve tunnel access, as documented in the Subversion Red Book? > That's what we're doing but the repository is owned by a separate user > as an additional security measure so that if someone somehow gains > shell access to the shared account, they won't be able to delete the > repository or anything like that. Do you think there's anyway to make > it work this way? > > Thanks for the help.
Don't give the shared "svn" user a valid shell!!!! If an administrator needs to run operations as that user, to manipulate config files or create new repositories, they can do "sudo -s -H -u svn" to get a valid shell as the administrative user. Sudo can even be configured to allow designated users such administrative access without requing local root privileges at all. It's common to set the permissions of all files, except the "db" directory and its contents, to "read-only" for the shared user, even making them root owned to protect them, and I've heard of leaving a cron job that locks down the individual revisions to avoid just what you describe. But there's limits, and setting svnserve to "suid" or "sgid" is not something I've seen anyone actually try. I'm afraid that, for example, it's not properly handling the limited shell access necessary to run the "pre-commit" tasks in your setup.