On Wed, Jan 5, 2011 at 12:31 PM, Nico Kadel-Garcia <nkadel_at_gmail.com>wrote:
> On Tue, Jan 4, 2011 at 4:56 PM, Daniel Becroft <djcbecroft_at_gmail.com>
> wrote:
>
> > svnadmin create .\repository
> > svnserve -r .
> >
> > and a repository is created and served via svnserve. With the above
> > defaults, a third step is required, which can get tedious. I'd propose
> > enabling svnserve by default, and it can then be disabled if required.
> This
> > also maintains the ease of creating test scripts to try and reproduce
> > issues.
>
> It's *too* easy.
And that's a problem .... why?
> Since the default svnserve.conf is very permissive,
> and because default svnserve is on an unprivileged port so any user
> can serve anyone else's "readable" repository to outside access,
>
The port that it runs on by default is irrelevant. svnserve can be started
to run on 'any' open port, so why does the default port matter? If someone
wanted to, they could run svnserve on port 80.
> without the original author's knowledge or explicit consent. The
> default permissions of "svnadmin create" and "svnadmin hotcopy" are
> much too permissive, and the concatenation of separate "the admin
> should set these if they want" options creates a quite noticeable
> security risk.
>
I think the notion of "too permissive" is the problem. My definition is
going to be different from yours, which is going to be different to the man
on the corner.
I don't have an issue with adding something to lock down a given repository
from not being served by svnserve, but I'm questing why it should be
restricted _by default_. As a user, if I wanted to try using SVN for the
first time, the simpler it is to setup a repository and use it, the better.
And, as I mentioned before, this is also applicable when creating and
destroying sandpit repositories to reproduce bugs or test ideas.
All I'm asking for, is that 'svnadmin create' (both with and without this
proposed change) should create a repository that can be served using the
provided svnserve, without modifying any configuration files. Add a new
configuration file, or new command-line options to switch it off, but leave
the default alone.
> Stefan's more sophisticated "let's set up a configuration file that
> restricts forms of access" is interesting, but would be at least 2
> years away from release given the burden of other critical issues in
> subversion-1.7 planned changes, and would be awkward to backport to
> "enterprise" systems such as the extremely out of date
> subversion-1.4.x on RHEL 5.
>
Received on 2011-01-05 04:26:28 CET