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