On Thu, Jun 25, 2009 at 01:54:10PM +0200, Johan Corveleyn wrote:
> > > Well, it's good to know development effort is being spent on
> > improving
> > > HTTP Subversion access, especially as it seems that svn:// access
> > is
> > > very much downplayed (and not developed?).
> >
> > What's missing for svn:// which needs to be developed?
> >
> > It supports quick and simple setup and SSH encryption.
> > That's what it's for. All the "heavy" features are left for HTTP.
> > E.g. svnserve can't even bind to more than one IP address,
> > unless it's being run by inetd.
>
> IMHO svnserve misses one very important feature: LDAP authentication.
>
> See this thread for those who think you can use LDAP via
> svnserve+SASL: http://svn.haxx.se/users/archive-2009-06/0536.shtml
>
> I must say that I was quite disappointed, when searching the
> mailinglist archives, to see that a patch to get LDAP support directly
> into svnserve (without SASL) was rejected:
> http://svn.haxx.se/dev/archive-2008-02/0081.shtml
>
> I can understand the dev's arguments about increased maintenance cost
> etc., but this is just such an important feature. Maybe nobody at the
> time realized that svn+SASL+LDAP just doesn't work ...
Note that Eric is not active anymore these days (he could still
veto the change but I guess he won't care much...)
But I see the following (different set of) problems with it,
in order of importance:
- It introduces a dependency on the ldap library even though this
should (in theory) already be supported by SASL.
There's a better short-term solution, see patch at the end of this mail.
- As far as I can tell it sends passwords in plaintext, so unless
you're running your ldap server and svnserve on the same box,
you're going to have problems with clear text passwords being
exposed on your network. To work around this you could set up
an encrypted connection via a VPN or stunnel or similar means.
But the same workaround can be used for existing SASL support
(again, see patch at end of this mail).
- It introduces a dependency on the ldap library without adding
the necessary config foo to the configure script
- It does not follow our coding conventions consistently, some of
the spacing looks really wrong
> In a commercial setting, being able to authenticate with LDAP (often
> more specifically AD) is essential. In a lot of companies, every
> service provided by IT authenticates with that single LDAP. Users only
> need one password to access all kinds of things (logging in into your
> pc, accessing the wiki, intranet, extranet, ...). If you change your
> password in Windows (which you have to do every X months), it's
> changed in the LDAP, so it's changed for all those services. It's your
> "company password" that you use for all IT stuff in the company.
I know these setups and their advantages and disadvantages.
Back in college we had to administrate an LDAP setup like that
and I'm glad I didn't have to deal with it much.
> You'd have a very hard time convincing the IT department to set up a
> separate (cleartext/obfuscated) database with passwords, separate from
> the LDAP, just to set up SVN. Are they going to keep it in sync with
> the LDAP (with some script-fu), or do your developers need to have
> another specific password, just for SVN (and how will you let them
> change it etc)?
>
> For us this was a deal-breaker to use svnserve. We had no choice but
> to go for apache+svn in the end. This is ok, but in reality this
> means: svnserve is not usable in a company setting.
I would not generalise like that. Many companies are fine with
authenticating svnserve via SSH.
Plain svn:// over public networks is obviously meant for read-only
access anyway, because it cannot encrypt passwords.
All this would change if someone added SSL support.
Also, in the mean time, we could relax the requirements of svnserve's
SASL support, and stop assuming that SSL is the only means of securing
the PLAIN and LOGIN mechanisms. See patch below.
If we then also amended the documentation to tell people to set up
a VPN or stunnel or similar to secure communication to saslauthd,
that's fine by me.
Would this make you happy?
Would you be willing to make the necessary documentation updates?
Stefan
[[[
Stop assuming that SSL is the only way to secure PLAIN and LOGIN
mechanisms. Until svnserve gains SSL support, people can secure
communication to saslauthd by other means, such as VPNs, stunnel, etc.
This should allow LDAP authentication with svnserve, but it's the
user's responsibility to make sure plaintext passwords aren't leaked
to the network.
* subversion/libsvn_ra_svn/cyrus_auth.c,
subversion/svnserve/cyrus_auth.c
(new_sasl_ctx, cyrus_auth_request): Don't set SASL_SEC_NOPLAINTEXT.
]]]
Index: subversion/libsvn_ra_svn/cyrus_auth.c
===================================================================
--- subversion/libsvn_ra_svn/cyrus_auth.c (revision 38192)
+++ subversion/libsvn_ra_svn/cyrus_auth.c (working copy)
@@ -351,10 +351,8 @@ static svn_error_t *new_sasl_ctx(sasl_conn_t **sas
sasl_errdetail(*sasl_ctx));
}
- /* Set security properties. Don't allow PLAIN or LOGIN, since we
- don't support TLS yet. */
+ /* Set security properties. */
svn_ra_svn__default_secprops(&secprops);
- secprops.security_flags = SASL_SEC_NOPLAINTEXT;
sasl_setprop(*sasl_ctx, SASL_SEC_PROPS, &secprops);
return SVN_NO_ERROR;
Index: subversion/svnserve/cyrus_auth.c
===================================================================
--- subversion/svnserve/cyrus_auth.c (revision 38192)
+++ subversion/svnserve/cyrus_auth.c (working copy)
@@ -282,9 +282,6 @@ svn_error_t *cyrus_auth_request(svn_ra_svn_conn_t
/* Initialize security properties. */
svn_ra_svn__default_secprops(&secprops);
- /* Don't allow PLAIN or LOGIN, since we don't support TLS yet. */
- secprops.security_flags = SASL_SEC_NOPLAINTEXT;
-
/* Don't allow ANONYMOUS if a username is required. */
no_anonymous = needs_username || get_access(b, UNAUTHENTICATED) < required;
if (no_anonymous)
Received on 2009-06-25 15:11:39 CEST