On Sat, Jul 2, 2011 at 5:17 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Could you please be more precise? svn+ssh:// is completely fine (if you > configure authorized_keys(5) correctly), it's admins who give their > users filesystem write access to the repository directory who are the > problem.
I consider svn+ssh the closest thing to remotely securable access for Subversion. I didn't mean to deprecate it in any way. I may have misunderstood the phrase "possibly some Apache configuration tweaks" to mean doing path based control on the Apache server side. This is surprisingly common: I've been forced to use it several times for employers. The problem is that if it's done purely in the Apache configuration, that access control will have no affect on file:// or svn+ssh:// based access, and this is actually what the "Subversion Red Book" describes. svnserve path based access control, which is what svn+ssh uses, is entirely distinct from Apache access control in the examples. I've not personally used both at the same time because the security model winds up very confused. Getting Subversion services under "suexec" doesn't work, and putting in authorized_keys for the apache daemon owner gets....... crazy making. So you wind up doing things like common group ownership and sgid directory settings, which are *not* propagated by svnadmin hotcopy. So running both access methods at the same time, with anything other than read-only public access for the Apache service, gets nutty.
