On Fri, Jul 30, 2010 at 12:17:50PM -0400, Nico Kadel-Garcia wrote:
> 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.
I still don't understand what kind of setup you are describing.
Is this with SSH or svnserve + SASL?
> > 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.
$ svn checkout https://www.example.com/repository/trunk repository_trunk
Authentication realm: <https://www.example.com> Example
Password for 'user':
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:
<https://www.example.com> Example
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/user/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)?
If you have suggestions for improving this warning, they are welcome.
But I think it is pretty straightforward already?
> >> 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.
Sounds like you have not understood how to set up svn+ssh:// securely.
If you set svn+ssh:// access up securely by restricting the command
users can execute to the svnserve binary (as advised in the
documentation), there is no such issue.
You don't get a shell prompt. All you get when you connect via SSH
is a warm welcome message from svnserve, in svn protocol.
It looks something like this:
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) )
If you know of a way to change hook scripts by talking svn protocol
to the svnserve binary, please let us know how you do it.
Because, yes, that would be a security issue.
Stefan
Received on 2010-07-30 19:20:49 CEST