On Wed, Dec 29, 2010 at 09:03:16AM -0800, Philip Prindeville wrote:
> On 12/29/10 8:34 AM, Nico Kadel-Garcia wrote:
> >On Wed, Dec 29, 2010 at 11:01 AM, Stefan Sperling<stsp_at_elego.de> wrote:
> >>The initial concern raised in this thread was that there might exist
> >>a hypothetical exploit of svnserve. I'm not sure if Philip was concerned
> >>primarily about unauthorised access to repositories due to such an
> >>exploit, or access to the server system itself. In the latter case,
> >>your proposed change wouldn't make any difference.
> >That's unclear, I agree. I've taken it in a slightly different
> >direction, trying to address his concerns.
>
> So my concern is this: I want to be able to easily, clearly, and with
> high confidence set up SVN to *only* work via Apache, and no other
> way. And I think that it's not unreasonable for the admin to be able
> to tell "svnadmin create" which access method he plans on using.
That was clear from the beginning. However, you motivation for wanting
this is still unclear to me.
Is it because you're afraid of an svnserve exploit that would grant
someone else access to your system?
Is it because you're afraid of an svnserve exploit that would grant
someone else access to your repositories?
Or is it something other than any of the above?
> Blaming the admin on software that's poorly designed and doesn't
> follow the most obvious of principles (the Principle of Least
> Astonishment being amongst them) is a cop out.
I can also argue with the Principle of least astonishment:
So say we've added a new svnadmin option --dont-create-svnserve-config,
and we've made svnserve skip repositories which don't have an
svnserve.conf file within them (putting aside the still unsolved problem
of what svnserve should do when run with a single global config file).
Now, from your point of view the problem is probably solved.
However, it doesn't end there for me. As a developer I need to consider
more use cases than those of just one user.
What if the user later decides to use svnserve instead of apache?
How would the principle of least astonishment be applied then?
Do we tell those users to copy svnserve.conf from another repository?
Do we add a new option --create-svnserve-config to svnadmin as well?
What if the user now wants to prevent apache httpd from accessing one
particular repository, but still access some others?
You may conveniently argue that you don't care about this problem
because it doesn't concern you. But Subversion developers cannot just
add options and functionality without considering the overall use of
those features for *all* Subversion users. The tool needs to be general.
Because of this, in your case, I would prefer if you simply wrote a
simple wrapper script to create your repositories, instead of us adding
a new feature to svnadmin:
create-svn-repos.sh:
#!/bin/sh
svnadmin create $1
rm -f $1/conf/svnserve.conf
> Admins today have to be competent in operating a few hundred different
> subsystems. Let's cut them some slack.
IMO automation is a very good way of capturing this complexity.
The script above is one way of automating repository creation to
address your desire.
I would go as far as recommending to take a look at puppet, a flexible large
scale automation system for system administrators, to control your
Subversion setup and create your repositories. This way you can take
care of a lot of special requirements in an automated fashion. Everyone
has special requirements, which is of course fine, but everyone also
has *different* special requirements.
> I'm a dev, I don't even do admin regularly, but this fell upon me
> because we're short-handed right now.
>
> And I can say, as an admin a decade ago, that software that is simple
> and clear to setup and operate is a joy in an otherwise largely
> thankless job (since people only talk to you when things are broken,
> not when they work correctly).
I may be biased but I don't think a core Subversion setup is particularly
complex to set up. It gets a lot more complex if you integrate
Subversion with existing infrastructure and other tools. But there is not
much Subversion's developers can do to help people with this, other than
making sure that Subversion's solutions are as general, flexible, and
scriptable as possible.
> >The common approach *is* to use an unprivileged user. But see above:
> >the locking out of non-designated users from read or write access to
> >Subversion repositories is under-documented.
> >
> >Setting up repositories to do this for two users, such as "apache" and
> >"svn", is even more fun and creates its own security overlap issues.
> >Coupled with the "svnadmin hotcopy" lack of preservation of group
> >permissions or sgid bits, and it's even more adventuresome.
>
> Yes, exactly. This is what I'm concerned about: lack of more
> visible/obvious separation between what enables Apache and what
> enables svnserve.
I agree that the book could be improved here.
One issue is that the book is supposed to be about Subversion and not
UNIX administration. However, putting hints into the book about what
to do on UNIX systems is fine, preferably with references to other
literature that describes these issues in detail.
Note that the book, just like Subversion itself, is an open source
project and that contributions to the book are not only welcome
but needed (see http://svnbook.org).
> Agreed. If you have the opportunity to make the software easier to
> use, why not do it?
We're trying to improve usability, all the time.
But there are many ways to make the software easier to use, and we
need to pick those that most of our users will benefit from.
Stefan
Received on 2010-12-30 15:30:04 CET