On 1/1/11 8:29 PM, Nico Kadel-Garcia wrote:
On Thu, Dec 30, 2010 at 9:29 AM, Stefan Sperling<s...@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.
Agreed. Can someone fill a bug to track this and put me as the buddy?
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.
Again, agreed.
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
Hmm... "$@" to handle options?
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.
True. Not to mention the lost time of all 300 different admins having to
figure this out and reinvent the wheel.
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.
Yup. In our case, we have IP that needs to be protected.
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?
Agreed. No need to reinvent the wheel.
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.
So you're ok being made redundant and slaughtering this cash-cow? :-)
-Philip
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.
