On Thu, Jul 21, 2011 at 11:05 AM, Daniel Neuberger
<daniel.neuberger_at_gmail.com> wrote:
> On Thu, Jul 21, 2011 at 10:51 AM, Nico Kadel-Garcia <nkadel_at_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.
Received on 2011-07-21 20:13:45 CEST