svn commit hangs over https+kerberos

[GoogleCodeExporter]

What steps will reproduce the problem?
1. from my account I do su root (with domain passwd)
2. svn commit -m "test"
3. now svn hangs forever

In apache log I see lots of:
[Fri May 30 15:54:08 2014] [error] [client 172.20.4.10] access to 
/portage-overlay/!svn/me failed, reason: user 'root' does not meet 
'require'ments for user/valid-user to be allowed access

I expect svn/serf to use my normal user credentials(as svn 1.7.x does) instead
of insisting on root's creds.

On gentoo linux with subversion 1.8.9 and serf 1.3.5(tried serf in svn trunk 
too) 

Original issue reported on code.google.com by joakim.t...@gmail.com on 30 May 2014 at 3:18

[GoogleCodeExporter]

Is this forum still alive? I see issues besides mine but no activity in them.

Original comment by joakim.t...@gmail.com on 10 Jun 2014 at 5:35

[GoogleCodeExporter]

Sure the issue tracker is still alive, it's just that not many people here are 
specialized in Kerberos (including myself).

Serf uses the default credentials when initializing a security context. This 
basically leaves it up to the Kerberos implementation to decide which user to 
use. 

In your case apparently this is the root user. Since you're using the domain 
password I suppose it's normal that Kerberos will use the ticket you got by 
logging in as root user.

Neon, the http library used by svn 1.7 use the same mechanism, by providing 
GSS_C_NO_CREDENTIAL to gss_init_sec_context it lets the Kerberos implementation 
choose which user to use.

Can you check if svn 1.7+neon manage to authenticate over Kerberos, or if they 
fall back to another authn scheme?

If you can get me a network trace of both the working 1.7 and not working 1.8 
scenario's I'll review them and see what's going on.

Original comment by lieven.govaerts@gmail.com on 12 Jun 2014 at 11:28

• Changed state: Accepted

[GoogleCodeExporter]

Managed to do some testing from home:
svn 1.7.17:
  su   --- works
  sudo --- works

svn 1.8.9:
  su   --- fails
  sudo --- works

Original comment by joakim.t...@gmail.com on 14 Jun 2014 at 3:00

[GoogleCodeExporter]

hmm, previous comment was not 100 % correct, I was using local root pw for 1.7
here is what happens with 1.7 and domain root pw:

svn commit -m "su + svn 1.7" 
Authentication realm: <https://devsrv.transmode.se:443> transmode.se
Password for 'jocke': 
Sending        layout.conf
Transmitting file data .
Committed revision 661.

So here one get a question to supply the pw(something I had forgotten).
Maybe you can figure out what to do from here?

Original comment by joakim.t...@gmail.com on 14 Jun 2014 at 3:06

[GoogleCodeExporter]

Joakim,

we have been discussing possible root causes in the serf-dev mailing list. It 
would help us a lot if you could enable logging in serf and then run the same 
commands, so we can see what exactly gets sent/received by serf.

You'll need to build serf from source. I propose you use the latest 1.3.x 
branch, and enable in serf_private.h: SSL_VERBOSE, SSL_MSG_VERBOSE, 
SOCK_VERBOSE, CONN_VERBOSE, AUTH_VERBOSE. You can send the logging to me 
privately.

Lieven

Original comment by lieven.govaerts@gmail.com on 23 Jun 2014 at 8:12

[GoogleCodeExporter]

How can this be a Kerberos problem is challenged in #4 for a password? This 
seems to be Basic/Digest.

Original comment by 1983-01...@gmx.net on 26 Jun 2014 at 9:16

[GoogleCodeExporter]

Lieven, I am on vacation now and for a few more weeks so will be hard to get 
some logs

However, as comment #6 suggests, this is not a Kerberos per say. Rather Serf 
should abort Kerberos after the first auth failure and fallback to Basic/Digest 
using
my real login name.
Currently Serf just retries Kerberos with root privs endlessly.

You could try using my login Kerberos creds before falling back to Basic/Digest.

I should mention that sudo works fine

Original comment by joakim.t...@gmail.com on 6 Jul 2014 at 9:47