On Thu, Dec 30, 2010 at 9:29 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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?
I personally covered this one. Make it part of the next release, push
svnserve.conf.tmpl instead of svnserve.conf in default configurations,
and make svnserve choke if there is not an svnserve.conf for the
particular repository.
This makes new setups disabled by default, but previous release
configurations still work unmodified and after "svnadmin hotcopy". It
changes the security model moving forward to a safer one. And yes, it
needs to be documentd. The existing "svnserve operates wide open
without an existing svnserve.conf" is an undocumented misfeature, and
a surprisingly dangerous one for repositories that may have sensitive
information in them.
> 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:
Until he goes to a new setup and has to send someone else his tool.
Better to perform saner security and disable services by default than
force manual deletion by every admin.
> create-svn-repos.sh:
> #!/bin/sh
> svnadmin create $1
> rm -f $1/conf/svnserve.conf
And *this* is why it should be automated, rather than expecting admins
to do it themselves. Because this script is.... Well, it's
historically typical of Subversion internals. It ignores the results
of the "svnadmin create" directive, and doesn't sanitize the inputs to
prevent scubbing an svnserve.conf from an already existing directive,
nor is it safe against misparsing a reponame with spaces or control
characters in it. If I knew such a script was run automatically by the
Subversion admin, I could trivially hand them a repository name that
would "rm -f \-r\ /\ repoanme".
You've just made my point that it should be automated upstream. But if
you really must do this, try something like the script below, although
it might need a bit more thought.
#!/bin/sh
# create-svn-repos.sh - Create Subversion repos with svnserve config eliminated
# Note that it does not handle any svnadmin options
#
progname="`basename $0`"
if [ $# -ne 1 ]; then
echo "Usage: $progname reponame"
exit 1
fi
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.
*Good* automation is helpful. Bad automation, and replacing automation
with locally developed ritual, is not.
This is absolutely correct. It should be automatic in svnadmin default
behavior, not in 300 hand-written add-on wrappers for 300 different
admins.
> The script above is one way of automating repository creation to
> address your desire.
This is clearly wrong. I've just reverified it. As you'd mentioned
previously, a missing svnserve.conf allows full read-access, without
restriction. It doesn't accept write commands, but read can be too
much in many configurations.
> 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.
Potentially useful, but why should he and every configuration tool
have to replace something that can be addressed more cleanly upstream?
> 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.
To set up the first time for testing? No. To set up securely? Youch.
It's paide me some very remunerative consulting wages, becuase it took
someone as paranoid as me to clean it up. It's quite painful due to
lack of documentation of necessary single-user configurations, the
multiplicity of access technologies each with entirely different
access control tools, and the expectation that each admin will *of
course write their own little wrappers for standard, sensible
behavior.
You just gave an *excellent* example of.the risks of.this with that
dangerous shell script. I really have to thank you for that unintended
blessing in this discussion.
>> >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.
See, that's where you're making another dangerous assumption. This is
not a "UNIX" suggestion. This is suggestion inherent to every ACL for
filesystems in the world, whether UNIX, Linux, MacOS, Windows, or even
some weird upstream network file system based setup.
> 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
And that's fair. Here's a very lightweight, testable, and reverse
compatible change that would notably improve security models going
forward. Enjoy.
Received on 2011-01-02 04:30:00 CET