On Sat, Jul 2, 2011 at 5:17 PM, Daniel Shahaf <d.s_at_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.
Received on 2011-07-03 02:05:10 CEST