On Fri, Jul 30, 2010 at 8:49 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Jul 30, 2010 at 07:56:50AM -0400, Nico Kadel-Garcia wrote:
>> Don't use LDAP. One problem is that it will allow multiple users
>> filesystem access to the Subversion repository, and *SOMEONE* is
>> likely to screw it up for everyone else by trying to manually edit
>> something in the repository in a large environment with multiple
>> developers.
>
> I don't see any way how using LDAP with Subversion would allow local
> filesystem access to users. Can you explain?
It has to allow local filesystem access on the Subversion server
itself: the Subversion repository needs to be accessible to the LDAP
clients on that host.
My use of the phrase "local filesystem accesm" was unclear in this matter.
> By default, it will *ask* you, not warn you. It only saves the password
> if you say "yes". That is not the same as printing a warning and
> saving it by default.
I focused on the fact that it does now warn you of the risk.
>> There are reasons the 'svn+ssh' approach channels all connections
>> through a single authorized repository owner,
>
> The only reason for a single SSH user is that you don't have to create
> unix system accounts for each committer. It's just for convenience.
> There are no additional security implications if you set up multiple
> ssh accounts, one for each committer.
Yes, there are. All the SSH users need write permission to the
Subversion repository itself, especially the database files. Unless
the hooks and conf subdirectories are carefully blocked from SSH user
access at setup time for the repository, and correctly replicated for
"hotcopy" and preserved from backup restoration, it becomes possible
for anyone with write access to the reository to replace the
"pre-commit" or "post-commit" hook scripts and wreak havoc on
unsuspecting users, even by accident.
Security infrastructure is not Subversion's strong point.
>> and uses the SSH
>> authorized_keys set to configure the svnserve command and to set the
>> user for committing changes; it's described in detail in the
>> Subversion Red Book, The missing component for this approach is a tool
>> to manage the SSH keys. If anyone has such a tool, or better a
>> management GUI to manage such keys, please publish it.
>
> There are lots of such tools for many platforms.
Name two.
Received on 2010-07-30 18:18:27 CEST