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. > 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.