> can anyone tell me wtf I'm missing in the commands below? > > # mkdir foo > # cd foo > # mkdir bin dev > # cp -p /bin/cat bin > # cd dev > # /dev/MAKEDEV std > # cd .. > # chroot . /bin/cat /dev/stdin > cat: /dev/stdin: Device not configured > > The reason I ask is that I need to run tar -czf within a chroot > environment, but gzip(1) tries to open /dev/stdin and fails (as the > contrived invocation of cat(1) in the example above).
A few comments. /dev/stdin is not apart of POSIX. It is not required that it even work. And after a recent security fix, it does not work like people think it does. Secondly your process running inside the chroot space is potentially tainted. It has a "past" which contains different uid's and gid's or such, see "man issetugid". In such a situation of "taintedness", even POSIX rules does not apply, and OpenBSD asserts a variety of security measures. Most are invisible, as in, some are now nearly 10 years old and noone has ever noticed. Setuid/setgid programs operate under greater constraints. Thirdly, we have recently added some security code to prevent a problem with /dev/fd/# (and thus /dev/stdin and friends) which could be a problem. Regarding our solution, I was positively laughing when I saw that Secunia and other similar sites/lists called it an OpenBSD-only problem, when every other operations system has this problem. Mapping fd#'s to device filenames is fundamentally a very stupid idea -- people often ignore the consequences of the conveniences they build. Thus, even though everyone has the problem, only OpenBSD has prevention for it. EVERYONE ELSE STILL HAS THE BUG. (That said, I did a couple of hours of reading our tree and found no setuid/setgid programs or daemons which would exercise the bug. So we basically removed the backbone of an insecure mechanism, even though we found nothing which could trigger it. Some of the convenience had to be sacrificed since the original designed of /dev/fd and /dev/stdin acted like an irresponsible retard by not considering the consequences. Whoever it was, say nearly 20 years ago, they were a very stupid idiot.) There were a few minor fallouts from our diffs, in compress/gzip in particular, but Todd Miller has put some effort into fixing those in very new code. For those interested in the actual problem, I will not go further. Go read the diff and think about what we are trying to do.
