BROKEN_FD_PASSING (Bug 269)

[Jim Knoble]

Circa 2002-Jun-27 13:18:13 +0200 dixit Thomas Binder:

: On Wed, Jun 26, 2002 at 02:32:36PM -0400, Jim Knoble wrote:
: > : Nope, at least not for me on i386-Linux 2.0.39, as it already
: > : breaks earlier with:
: > : 
: > : mm_receive_fd: recvmsg: expected received 1 got 2
: > 
: > Is that repeatable?  Can you strace it?
: 
: It is repeatable, but astonishingly not straceable.
: 
: Calling
: 
: ./sshd -p 2222 -d -d -d
: 
: and connecting as a user (authenticated via public key; it does
: not fail when connecting as root, btw.) will result in
: 
: mm_receive_fd: recvmsg: expected received 1 got 2
: 
: As soon as I add strace, as in
: 
: strace -f -o /tmp/strace.user ./sshd -p 2222 -d -d -d
: 
: it fails with the "expected" message
: 
: mm_receive_fd: expected type 1 got 1074277169
: 
: (unless patched as suggested).
: 
: Running as a daemon behaves as in case 1, i.e. needs
: BROKEN_FD_PASSING.
: 
: Further investigating this issue, I found out that linking with
: TransArc's AFS libraries is the culprit. Without them,
: everything's fine (except, of course, one can't login as a user).
: 
: Thus, it seems to be a local problem only, nothing to worry about
: here. Of course, it unfortunately forces me to define
: BROKEN_FD_PASSING, but I'll have to live with that.
: 
: But it's really interesting that running sshd with and without
: strace behaves differently.

That is indeed very weird.

I wonder if the AFS libs are somehow sending another control message
that the recvmsg() call in mm_recieve_fd() is intercepting....

Sounds like BROKEN_FD_PASSING is the workaround for you (unless you're
able to upgrade your Linux kernel to v2.2.x).

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 262 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020627/3763a33d/attachment.bin