Distribution: Redhat 8 w/2.6.0-test7 Hardware Environment: AMD K6III/500, 256MB RAM Software Environment: gcc-3.2-7, glibc-2.3.2-4.80.6, openssh-3.7.1p2 Problem Description: Basically, processes lauched from sshd without a pty can't access /proc/self/fd/0. This is an update to bug #1357 which has been closed as invalid (because it was a 2.4 vendor kernel). I can reproduce with a vanilla 2.6.0-test7 kernel but I can't reopen the bug. I'm guessing this in an issue with /proc, hence the "Filesystem" category, however I could be wrong. Steps to reproduce: $ ssh testbox "uname -a" Linux testbox 2.6.0-test7 #11 Wed Oct 15 20:35:16 EST 2003 i686 unknown $ echo test | ssh 192.168.32.108 "cat /proc/self/fd/0" cat: /proc/self/fd/0: No such device or address $ echo test | ssh testbox "cat | cat /proc/self/fd/0 | cat" test In the failing example, the descriptor is a socket. In the working example, the descriptor is a pipe. I don't know if this is related. $ ssh testbox "ls -l /proc/self/fd/" lrwx------ 1 root root 64 Oct 16 04:50 0 -> socket:[2474] lrwx------ 1 root root 64 Oct 16 04:50 1 -> socket:[2474] lrwx------ 1 root root 64 Oct 16 04:50 2 -> socket:[2476] lr-x------ 1 root root 64 Oct 16 04:50 3 ls: ls:/proc/self/fd/3: No such file or directory $ ssh testbox "cat | ls -l /proc/self/fd/ | cat" lr-x------ 1 root root 64 Oct 16 04:51 0 -> pipe:[2556] l-wx------ 1 root root 64 Oct 16 04:51 1 -> pipe:[2557] lrwx------ 1 root root 64 Oct 16 04:51 2 -> socket:[2554] lr-x------ 1 root root 64 Oct 16 04:51 3 ls: ls:/proc/self/fd/3: No such file or directory (Also occurs on kernel-2.4.20-20.8, and self-made embedded system with VIA Ezra CPU, 2.6.0-test7 kernel + uClibc-0.9.19 + busybox userspace) I have a stand-alone test case which I will attach.
Created attachment 1062 [details] Demonstrate ENXIO error opening /proc/self/fd/0 # uname -a Linux dingo 2.6.0-test7 #10 Sat Oct 11 02:44:22 EST 2003 i586 i586 i386 GNU/Linux # gcc kerntest.c # strace -f ./a.out execve("./a.out", ["./a.out"], [/* 20 vars */]) = 0 uname({sys="Linux", node="dingo", ...}) = 0 brk(0) = 0x804a000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=61138, ...}) = 0 old_mmap(NULL, 61138, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210U\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1377691, ...}) = 0 old_mmap(NULL, 1219172, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40022000 old_mmap(0x40144000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x121000) = 0x40144000 old_mmap(0x4014a000, 6756, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014a000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014c000 munmap(0x40013000, 61138) = 0 close(0) = 0 close(1) = 0 close(2) = 0 socketpair(PF_UNIX, SOCK_STREAM, 0, [0, 1]) = 0 fork() = 874 [pid 874] close(1) = 0 [pid 874] dup2(0, 0) = 0 [pid 874] dup2(0, 1) = 1 [pid 874] open("/proc/self/fd/0", O_RDONLY|O_APPEND|O_NOCTTY|O_LARGEFILE|0x8040030) = -1 ENXIO (No such device or address) [pid 874] wait4(-1, 0xbffffb70, 0, NULL) = -1 ECHILD (No child processes) [pid 874] _exit(-1) = ? wait4(-1, 0xbffffb70, 0, NULL) = -1 ECHILD (No child processes) _exit(-1)
Is this still a problem in recent kernels, like 2.6.14?
I suspect so but can't confirm as I'm running vendor kernels. There was some followup on the netdev list (http://oss.sgi.com/archives/netdev/2003-10/msg00508.html) which indicated that it was not trivial to fix. I just checked the 2.6.14 source and the function mentioned by Andrew has not changed. You can verify by running the testcase attached to this bug under strace: if you see EXNIO then it's still a problem.
Still a problem in 2.6.17-rc4, at least, ssh'ing from my x86_64 box to my i386 box, with the exact same commands as Darren, I get "cat: /proc/self/fd/0: No such device or address" for the first, and "test" for the second. Thanks, Nish
The choice to not allow open() calls on sockets was deliberate. It's not a bug. This report should be closed.