On 12/30/10 7:29 AM, Stefan Sperling wrote:
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<s...@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?
Yes.
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.
What I inconveniently care about is that the software be secure, and in being
secure, that it be easy to set up so that it does what I want it to do, and no
more (i.e. that it not leave any doors open unintentionally).
I don't care how you do that. As long as it's easily understandable,
preferably to both existing users and new ones.
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
You could also ship the product with scripts to achieve common tasks. Users
who already know how to set it up would look at the scripts, infer what the do,
and make the choice to use them or not.
New users could use the script that most closely corresponds to what they are
trying to achieve.
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.
Ah. So you're suggesting that I double the complexity of my task (if not more).
You did see where I said I was a developer, and merely happened to end up with
the task of setting up the repo just because no one else was available to do
it, right?
In addition to the principle of least astonishment, maybe I'll invoke K.I.S.S.
as a cannon in my credo.
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.
True, but as you point out, a few handy common wrappers can go a long way.
I wouldn't mind seeing support for SSL certificate generation via openssl...
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).
I acknowledge the hint and I'll consider it. I'm currently spread across 40+
OSS projects... mostly on a crusade to add QoS to common network services (ntp,
Firefox, Cyrus, Thunderbird, Sendmail, wget, libcurl, APR/Apache, Proftpd, etc).
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
I understand.
-Philip
