On 09/02/12 18:26 -0400, Curtis Villamizar wrote:
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).
'unknown mech-code 0 for mech' appears in several sasl and non-sasl related
returns with a google search. I guess that it originates from heimdal.
Check your kdc logs. This could be something as simple as a dns
disagreement as to what principal the server should be using.
The order, as I understand it, is:
The client obtains a TGT from the kdc
The client initiates a connection with the svn server
The server returns with a string that contains the supported sasl
mechanisms
The client chooses an appropriate mechanism
If gssapi, then:
obtain a service ticket from the kdc
complete authentication with the svn server using the service ticket
(this step is where things appear to go awry, and points to a possible
service name mismatch)
Make sure that your server contains a matching keytab entry as in your
svn/<host>@<krb5-realm> output from above. Explicitly provide a hostname
within your svnserv.conf, for sasl initialization, if it allows for such a
configuration. If not, verify that 'hostname -f' looks correct on your svn
server.
If you restart your svn server, you should see which principal it is
requesting from your kdc (or at least, the first time it initializes sasl).
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
--
Dan White
