GSSAPIDelegateCredentials fails with a segfault

Darren Tucker dtucker at zip.com.au
Tue May 1 10:41:07 EST 2007


Simon Wilkinson wrote:
> On 30 Apr 2007, at 17:23, Johan Andersson wrote:
>> First off: Have anyone seen this before?
> 
> No, this is the first report I've seen of this problem.

I've seen something similar but with keyboard-interactive, which ended up being 
caused by a bug in glibc which was triggered by a name service lookup from inside 
a chroot.  It's possible that you're seeing the same thing (and it would explain 
why there's no core dump: the chrooted child does not have permission to write 
anywhere).

Try creating "dev" and "lib" directories inside your privsep dir (/var/empty by 
default) and if the problem goes away then this is the most likely cause.

[...]
> Privsep makes it pretty tricky to follow through all of the processes  
> with a debugger. Often the easiest thing to do is to instrument the  
> code. If it is dying where you think it is, then adding additional  
> debug statements to ssh_gssapi_krb5_storecreds is the best place to  
> start. In particular, it's worth seeing if the call to  
> gss_krb5_copy_ccache is succeeding.

The first thing I usually try is running in debug mode without privsep under a 
debugger.  If that doesn't exhibit the problem, I have been known to add a 
"sleep(60)" just after the fork in the child and attach a debugger to at that point.

Another possibility is to tell the kernel to write core dumps elsewhere 
temporarily (eg "sysctl kernel.core_pattern=/tmp/core; sysctl 
kernel.core_uses_pid=1") but I haven't tried this.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


More information about the openssh-unix-dev mailing list