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<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?
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
Received on 2011-01-02 07:58:58 CET