subversion svn/svnserve SASL with GSSAPI auth not working (for me)

[Curtis Villamizar]

I'm running FreeBSD 8.3, SASL 2.1.25_2 and subversion 1.7.5.  I'm
using the supplied heimdal (not from ports collection).

In a past life I swithed from a cvs repository using krb5 to svn using
GSSAPI but I don't have access to that config.  It was also 2008 and I
think it was subversion 1.5, the first to support SASL.

I've tried various combinations in svn.conf on the server side with no
luck.  The best I get is:

  % kinit
  <user>@<KRB5-REALM>'s Password:
  % svn checkout svn://<host>/trunk/home home
  svn: E170001: Unable to connect to a repository \
        at URL 'svn://<host>/trunk/home'
  svn: E170001: Authentication error from server: \
        SASL(-1): generic failure: GSSAPI Error:  \
        No credentials were supplied, \
	or the credentials were unavailable or inaccessible. \
	(unknown mech-code 0 for mech unknown)
  % klist
  Credentials cache: FILE:/home/<user>/.krb/_O
          Principal: <user>@<krb5-realm>
    Issued           Expires          Principal
  Sep  2 17:00:24  Sep  3 03:00:24  krbtgt/<krb5-realm>@<krb5-realm>
  Sep  2 17:04:35  Sep  2 21:04:35  svn/<host>@<krb5-realm>

[ line continue added for readability.  <user>, etc is an edit. ]

AFAIK there is no way to enable any sort of verbose logging of the
authentication on the client side without editing the SASL code.

On the server side all I get is:

  # su -m svn -c 'sh -c "/usr/local/bin/svnserve.bin -6 -X \
        --foreground --listen-port=3690 --listen-host <ipv6addr> \
	-r <repos-path>"'
  svnserve: E210002: Network connection closed unexpectedly

The above is with log level 7.  (Not very helpful IMHO).

Obviously since I got back svn/<host>@<krb5-realm> in klist, the server
side has found the krb5-keytab file.  On the server side the svn.conf
file contains:

  mech_list: GSSAPI DIGEST-MD5
  keytab: /home/svn/krb5-keytab
  log_level: 7

The svnserve.conf file in the repos contains:

  [general]
  anon-access = none
  auth-access = write
  realm = <krb5-realm>
  ### authz-db selects an authz file - see comments there
  ### force case of usernames when accessing authz-db file (none,lower,upper)
  #authz-db = authz 
  #force-username-case = lower

  [sasl]
  #  use-sasl disables all other authentication (A Good Thing (tm) imho)
  use-sasl = true
  min-encryption = 56
  max-encryption = 2048

[ aside : preliminary results of looking into the code ...

  I did some poking into the code of svn, svnserve, and sasl to see if
  there was any debugging or logging that could be enabled, or to just
  find a good place to add logging, but haven't found anything.

  The following yields nothing in the sasl code and subversion code:

    find * -type f | xargs egrep -l 'unknown mech-code|mech unknown'

  Probably a consequence of internationalization (further
  obstrufication).

  It appears as though the error is passed from the server to client
  based on "Authentication error from server" in the message.  That
  string is found in libsvn_ra_svn/cyrus_auth.c (client side) at line
  908, which is quite a ways down in svn_ra_svn__do_cyrus_auth and
  follows a call to try_auth.  try_auth calls sasl_client_start and
  I'm guessing that the "(unknown mech-code 0 for mech unknown)" in
  the error response has something to do with the "case SASL_NOMECH:"
  which is followed by "return
  svn_error_create(SVN_ERR_RA_SVN_NO_MECHANISMS, NULL, NULL);".

  If so, the tickets get passed about successfully indicating the
  GSSAPI was tried and succeeded, yet sasl_client_start returns
  SASL_NOMECH.  There is comment indicating that this in not handled
  (line 1248 in cyrus-sasl-2.1.25/lib/server.c).

  If plugin->mech_avail returns SASL_NOTDONE we could get SASL_NOMECH.
  If somehow SASL_NEED_PROXY or SASL_NEED_HTTP were set we could get
  SASL_NOMECH.  Perhaps these should have a sasl_seterror before the
  return statement (on or about line 1294 in server.c).

  The above are in mech_permitted in server.c, called by
  sasl_server_start.  Perhaps logging after that call would help.

  Following the conditional "if (m->m.condition == SASL_CONTINUE) {"
  at line 1424 is a series of "if (result == SASL_OK) {" conditionals,
  each doing a next step.  A better approach might be a "if (result !=
  SASL_OK) {" followed by a log message and a goto.  If goto is not
  liked, then do a "do ... while (0)" which always does the inside
  once (or "for (__i=0;__i==0;++__i)" if that is more clear) and then
  use a break rather than a goto.  This way each casue of failure can
  be logged.

... end aside ]

Perhaps someone on this list has a clue as to why I'm seeing this
problem.  Otherwise I'll edit the above code and send diffs that help
isolate the problem.  I then hope those diffs will be taken to make it
easier for the next person to figure out where a problem is coming
from without editing the code to do it.  Note that the diffs I'm
suggesting would not change what the code does, just add logging.

At best these diffs will point me closer to which plugging function to
look at (to then add logging to further isolate, ... and so on).

Curtis