On 9/28/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> 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.
All our restrictions would still be enforced (this means no ANONYMOUS
if auth-access is none etc.). Besides, this situation (SASL sending
all mechanisms) also happens if there is no mech_list option in
subversion.conf, which is perfectly OK. And there is no way we can
reliably detect the absence of subversion.conf, so we don't really
have a choice.
The fix I was proposing (falling back to other mechanisms if GSSAPI
fails) seems like a reasonable way to deal with these cases. The
jabber guys seem to agree with me:
http://j2.openaether.org/mediawiki/index.php/CyrusSASL#Client_considerations
> > 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
>
OK, I'll try again with pool debugging enabled. Although it's weird
that I didn't get any test failures, either.
--
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 21:37:00 2006