Authentication error from server: SASL(-13): user not found: unable to canonify

Question

Ok, so I'm trying to configure and install svnserve on my Ubuntu server. So far so good, up to the point where I try to configure sasl (to prevent plain-text passwords).

So; I installed svnserve and made it run as a daemon (also installed it as a startup script with the command svnserve -d -r /var/svn).

My repository is in /var/svn and has following configuration (to be found in /var/svn/myrepo/conf/svnserve.conf) (I left comments out):

[general]
anon-access = none
auth-access = write
realm = my_repo

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

Over to sasl, I created a svn.conf file in /usr/lib/sasl2/:

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/my_sasldb
mech_list: DIGEST-MD5

I created it in that folder as the article at this link suggested: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl (and also because it existed and was listed as a result when I executed locate sasl).

Right after that I executed this command:

saslpasswd2 -c -f /etc/my_sasldb -u my_repo USERNAME

Which also asked me for a password twice, which I supplied. All going great. When issuing the following command:

sasldblistusers2 -f /etc/my_sasldb

I get the - correct, as far as I can see - result:

USERNAME@my_repo: userPassword

Restarted svnserve, also restarted the whole server, and tried to connect. This was the result from my TortoiseSVN client:

Authentication error from server: SASL(-13): user not found: unable to canonify  
user and get auxprops

I have no clue at all in what I'm doing wrong. I've been scouring the web for the past few hours, but haven't found anything but that I might need to move the svn.conf file to another location - for example, the install location of subversion itself. which svn results in /usr/bin/svn, thus I moved the svn.conf to /usr/bin (although that doesn't feel right to me).

Still doesn't work, even after a new reboot.

I'm running out of ideas. Anyone else?

---

EDIT

I tried changing this (according to what some other forums on the internet told me to do): in the file /etc/default/saslauthd, I changed

START=no
MECHANISMS="pam"

to

START=yes
MECHANISMS="sasldb"

(Actually I had already changed START=no to START=yes before, but I forgot to mention it). But still no luck (I did reboot the whole server).

Answer 1

It looks like svnserve uses default values for SASL...

Check /etc/sasl2/svn.conf to be readable by the svnserver process owner. If /etc/sasl2/svn.conf is owned by user root, group root and --rw------, svnserve uses the default values. You will not be warned by any log file entry..

see section 4 of https://svn.apache.org/repos/asf/subversion/trunk/notes/sasl.txt:

This file must be named svn.conf, and must be readable by the svnserve process. (it took me more than 3 days to understand both svnserve-sasl-ldap and this pitfall at the same time..)

I recommend to install the package cyrus-sasl2-doc and to read the section Cyrus SASL for System Administrators carefully.

I expect this is caused by the SASL API for the call

  result = sasl_server_new(SVN_RA_SVN_SASL_NAME,
                       hostname, b->realm,
                       localaddrport, remoteaddrport,
                       NULL, SASL_SUCCESS_DATA,
                       &sasl_ctx);
  if (result != SASL_OK)
  {
    svn_error_t *err = svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
                                      sasl_errstring(result, NULL, NULL));
    SVN_ERR(write_failure(conn, pool, &err));
    return svn_ra_svn__flush(conn, pool);
  }

as you may see, handling the access failure by svnserve is not foreseen, only Ok or error is expected...

Answer 2

I looked in /var/log/messages and found

localhost svnserve: unable to open Berkeley db /etc/sasldb2: No such file or directory

When I created the sasldb to the above file and got the permissions right, it worked. Looks like it ignores or does not use the sasl database path.

There was another suggestion that rebooting solved the problem but that option was not available to me.