When enabling the Privilege separation, I get this message in line 117 (monitor_fdpass.c,v 1.3 2002/06/04 23:05:49 markus Exp $) It works ok on Linux 2.4.18 but not on 2.0.36 (Yes, I know I should upgrade) How can I help you to sort this out? I wasn't able to locate where CMSG_FIRSTHDR(...) was defined or struct cmsghdr dazo
Could you please check the error message again? Is it: mm_receive_fd: recvmsg: expected received 1 got nnnnnnnn or is it this: mm_receive_fd: expected type 1 got nnnnnnnn ? Those are two different problems, within a few lines of each other. The exact text of the error message is important.
The message I receive is: mm_receive_fd: expected type 1 got nnnnnnnn I added a little more debuging to be shure, and I'm 100% shure that the program failes in line 117 in the monitor_fdpass.c file.
Use the attached patch (against the openssh-SNAP-20020702 snapshot). An explanation is in the openssh-unix-dev archives: http://www.mindrot.org/pipermail/openssh-unix-dev/2002-June/013903.html
Created attachment 127 [details] Patch to enable mm_receive_fd() to work under Linux kernel-2.0.x
This isn't a security risk from what I can see. It's a risk of reading a bogus file descriptor (or the wrong file descriptor). If somebody can muck with your file descriptors enough to make this a security bug, then they're root already. :-) The fix for this, ideally, should be to detect the bogus value, report a warning in the system log, and continue. If you get a valid file descriptor, then clearly the message is really of the type expected, or else it's garbage. Either way, the worst it can do is maybe provide a really obscure local DOS attack.... As long as there are appropriate warnings in the system log about this being a kernel bug, it seems reasonable to work around it in this way. Please consider adding such a workaround to the official tree.
This seems to work! Thank ya'll! Dazo
Mass change of RESOLVED bugs to CLOSED