On 9/28/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> 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.
That seems reasonable. We shouldn't just fail on the first mechanism
that doesn't work.
> 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?)
Agreed that failing based on lack of subversion.conf when use-sasl is
off would be silly.
> 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.
I'm still waiting for a justification for why a user that turned on
sasl in svnserve.conf but didn't condfigure subversion.conf should do
anything other than deny all access to the system. Just defaulting to
all the SASL mechanisms (does that include ANONYMOUS? That would be
bad) seems incredibly bad to me.
> 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.
FWIW, David appears to be able to make this problem happen on Mac OS
X, so it's not just me ;-)
Could you try compiling your APR with --enable-pool-debug, and then
run svnserve under valgrind for the tests and see if you get any weird
errors? I use something like:
valgrind subversion/svnserve/svnserve -d --foreground -r
`pwd`/subversion/tests/cmdline
-garrett
---------------------------------------------------------------------
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:12:17 2006