On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>>
>> Yes, but the packaged linux versions pretty much just come up working
>> under http(s) with a appropriate line or two added to the packaged
>> configuration to point to the repository location, and once a network
>> server works, svnsync 'just works' to back it up from elsewhere.
>
> Les, I'm afraid that's handwaving. Like implementing Wikis and FTP
> sites, it leaves out the boobytraps. Let's look specifically at the
> HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good,
> and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has
> the profound flaw that it explicitly recommends creating the
> repositories owned by the "apache" user. But this leaves not merely
> the Subversion database, but the *configuration* and hook scripts for
> the Subversion repository owned by the "apache" user, so any other PHP
> script or poorly secured services running on that HTTP server can edit
> *anything* in the Subversion repository, unmanaged by and unknown to
> the repository maintainer.
So if it hurts, don't do that. It is hardly subversion's fault that
running other services under the same uid exposes all of those
services to more code that can be subverted - but you don't have to
run other services on the same machine and more specifically you don't
have to give people you don't trust administrative access to install
that code.
> Worse, there are setups where both HTTP and
> SSH are used to access the same repository. And suddenly pre-commit
> and post-commit scripts can be manipulated by another HTTP "apache"
> owned process, and later get run if *root* comes in via SSH.
If it hurts...
> Looking this stuff up in Google, or in the Red Book for Subverson, is
> not enough because the answers are incomplete. or disjoint, and often
> contradictory The underlying and historically evident attitude is that
> "security is your problem, you have to trust he machine you're working
> on".
Well the converse is certainly true and probably a much bigger issue.
If administrative access and access to the underlying files aren't
secure, all bets are off anyway and there are lots of ways for that to
go wrong besides the ones you mentioned.
> So summing up: simple "file:///" access is not going to properly
> introduce you to these issues.
In a way it does, since securing files (and keeping backups) underlies
everything.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-10-30 17:26:41 CET