On 10/11/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> I'm also having a problem with the SASL-enabled svnserve - and while it's
> not completely identical to the problem you're fixing here, I suspect
> it's in the same area.
>
> The problem I have is that if I link to the SASL libraries (which happens
> by default), I can no longer establish a non-SASL connection. That is,
> there appears to be no fallback from the SASL negotiation to the non-SASL
> negotiation (of anonymous, cram-md5).
>
> Specifically, I get the following error:
>
> $ basic_tests.py --url=svn://localhost:3691 1
> ../svn-trunk/subversion/libsvn_ra_svn/sasl_auth.c:339: (apr_err=170001)
> svn: SASL(-4): no mechanism available: No worthy mechs found
> FAIL: basic_tests.py 1: basic checkout of a wc
>
> Which, arguably, is correct, as I have no configured SASL mechanisms
> that can be used by the client to prove the user's identity to the server.
You shouldn't have to configure anything. A SASL-enabled svn is
supposed to be backward compatible with old servers _if_ the ANONYMOUS
and CRAM-MD5 plugins are installed on the system. (SASL mechanisms are
implemented as plugins which are dynamically loaded at runtime by the
main sasl lib). In your case, it's probably caused by a missing
ANONYMOUS plugin (there should be a libanonymous.so in
/usr/lib/sasl2).
Distros usually put SASL plugins in a separate package from the main
sasl lib (either all plugins in the same package or one package per
plugin). In that case, Subversion package maintainers will probably
have to add a dependency for the ANONYMOUS and CRAM-MD5 package(s), to
ensure backward compatibility.
> [Incidentally, I presume that these are done on a per-service basis or
> similar? We're not going to ship in a mode that suddenly allows every
> valid account in /etc/passwd to commit to a repository, are we?]
Yes, configuring the range of allowed mechanisms and the
password-checking method is done in a configuration file specific to
Subversion (usually /usr/lib/sasl2/subversion.conf).
> Anyway, the current situation is a not a good user experience, especially
> as I have no reason to enable SASL myself (though I _do_ need the SASL
> libraries to be installed for some other applications).
>
> Can we not fall back to the previous authentication mechanism if SASL
> doesn't have any matching authentication mechanisms?
>
I think it's simpler to just require users to have those plugins
installed than to complicate the SASL implementation.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 11 17:53:40 2006