On 9/28/06, David Glasser <glasser@mit.edu> wrote:
> On 9/26/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > So, I've been trying to figure out why the svnsync tests fail over
> > ra_svn when you turn on the server side sasl support. Here's what
> > I've come up with so far:
>
> In trying to track this down, I managed to make a bunch of dumb
> configuration mistakes. The biggest one was putting the
> Subversion.conf file in the wrong place for a pretty long time. Is
> there a way that we can detect that there isn't actually a
> Subversion.conf file? It doesn't seem like SASL works at all if there
> isn't one, so if use-sasl is true but there's no configuration file, I
> think svnserve shouldn't run.
Interesting. I would've expected SASL initialization to fail if there
is no subversion.conf file but apparently, this is not the case.
Instead I get errors such as this when I try to connect to the server:
svn: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure
(No credentials cache found)
This means that the server is sending a list of all possible
mechanisms, and the client selects GSSAPI because it is the most
secure. However, the client isn't really configured to use
GSSAPI/Kerberos, so it fails during sasl_client_start() because there
is no credential cache. The correct behavior in this case would be to
delete GSSAPI from the list of mechanisms and try again. I'll start
working on a patch for this right away.
To answer your question, there is no (reliable) way to detect that
subversion.conf is missing, and, in any case, this is not what we want
to do, for at least two reasons:
1. People who are using a SASL-enabled svnserve, but aren't setting
'use-sasl' to 'true' in their repos would be awfully surprised to see
svnserve fail because subversion.conf could not be found
(subversion.conf? what's that?)
2. Even if the admin set use-sasl to true, but there is no
subversion.conf file, authentication could still succeed if a) the
admin added the appropriate users to the database and b) we filtered
out failing mechanisms on the client-side, as described above. So, for
this use case (authenticating against sasl's own database),
subversion.conf would effectively become optional.
OTOH, I'm not able to reproduce the problem Garrett described (the
svnsync failures, or the valgrind errors). Everything seems to work
fine. I'm using Cyrus SASL 2.1.22 on a FC5 box.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 28 20:04:35 2006