That’s interesting. I never considered that this may be a negotiation failure between the svn client and server. It would explain why saslauthd doesn’t log anything.
I don’t know if SVN supports “PLAIN” explicitly, but according to the documentation at
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html it seems to be that it would rely entirely upon what SASL is compiled with. And I do have PLAIN compiled (libplain.so…. exists).
The only thing I see as relevant on the svn side is:
“SASL is also able to perform data encryption if
a particular mechanism supports it. […] To enable or
disable different levels of encryption, you can set two
values […]The min-encryption and max-encryption variables
control the level of encryption demanded by the server. To
disable encryption completely, set both values to 0. ”
So I tried:
[sasl]
use-sasl = true
min-encryption = 0
max-encryption = 0
And:
[sasl]
use-sasl = true
min-encryption = 0
max-encryption = 256
The results were exactly the same…
>NOTE: I am using Cyrus SASL 2.1.26 (self-compiled).
>1) saslauthd
>$ testsaslauthd -f /tmp/mysasl/mux -u ldapuser -p secret
>0: OK "Success."
>Now, I am a bit confused as to the SERVER (in my case subversion)
>application talking to saslauthd. For subversion (based on what I've
>read) I created an "/usr/local/etc/svn.conf" as:
>pwcheck_method: saslauthd
>saslauthd_path: /tmp/mysasl/mux
>mech_list: PLAIN
>
>The problem is that when I run my client, I see this:
>
>$ svn co svn://localhost:2008/trunk
>svn: E170001: SASL(-4): no mechanism available: Internal Error -4 in
>../../lib/server.c near line 1757
Can you manually select your mechanism with svn? Does svn require network
protection to use PLAIN?
>I'm not sure why svnserve doesn't like my config. I'm pretty sure it's
>picked up, because I used strace to run svnserve, (I thought I may be
>editing the wrong config file) and:
>
>$ strace svnserve --listen-port 2008 -r /tmp/testrepo
>[...]
>open("/usr/local/etc/svn.conf", O_RDONLY) = 3
>[...]
>
>So I'm pretty sure svnserve knows that it's supposed to use saslauthd,
>but it seems like it doesn't even *try* to talk to it: I ran saslauthd
>with "-d" to see what happens and nothing is logged!
>
>When I test with testlsaslauthd I see stuff like:
>
>[...some local cache lookup...]
>saslauthd[2514] :do_auth : auth success: [user=ldapuser]
>[service=myservice] [realm=myrealm] [mech=ldap]
>saslauthd[2514] :do_request : response: OK
Check permissions on /tmp/mysasl/mux
--
Dan White
