A bug no clue what causes this

Hello,

I was playing with pivotroot(8) chroot(1) in the last couple of days, and I found an abnormal behavior regarding the fd redirection in the chroot redirection command (look at pivotroot(8) examples). Later I figured out that this has nothing to do with pivotroot or chroot, but the "exec chroot" after pivotroot triggered it for me.

Anyways, here is the issue. Get a bash shell (or any shell). No matter if it is console, virtual terminal, xterm, or ssh. Figure out which tty the shell is connected to:

$ ls -lproc-$$-fd

Let's say, it isdev-tty1. (also remember the permissions.)

Then execute the following command (idea taken from pivotroot(8)).

Seemingly everything is OK. Now checkproc-$$-fdagain. The permissions are strange.

Now try to read a textfile (what else) with either less or more. It will quit after the first page, and this is the bug. Run it through strace. Here are my results:

First is a "problem free" environment, which is, before starting bash with the redirections.

#################### strace out starts ####################

open("-usr-share-locale-en-LCMESSAGES-util-linux.mo", ORDONLY) = -1 ENOENT (No such file or directory) write(1, "-337m--More--(31%)-3327m", 22--More--(31%)) = 22 read(2, "q", 1) = 1 ioctl(2, SNDCTLTMRSTART, {B38400 opost isig icanon echo ...}) = 0

#################### strace out ends ####################

I removed almost anything and left only the interesting stuff.

It read from fd 2, which is, theoretically, stderr. Anyways, I entered a "q" here to quit, and it worked.

stuff:

#################### strace out starts ####################

open("-usr-share-locale-en-LCMESSAGES-util-linux.mo", ORDONLY) = -1 ENOENT (No such file or directory) write(1, "-337m--More--(31%)-3327m", 22--More--(31%)) = 22 read(2, 0xbfffda33, 1) = -1 EBADF (Bad file descriptor) ioctl(2, SNDCTLTMRSTART, {B38400 opost isig icanon echo ...}) = 0

#################### strace out ends ####################

Here, it prints that 31% left, but when it tries to read from fd2, it fails with a Bad file descriptor. Why is it a bad fd?

If I leave out the stderr redirection from the invocation of the

But in that case, changing the root directory (read pivotroot(8)) will fail since the stderr from the old rootfs is used.

This bug has nothing to do with pivotroot and chroot, but they triggered it since I needed to do something that I don't do regularly (and nobody I suspect.) I tested it on a debian 3.1 box with 2.6.11.8 (own-compiled) kernel, another devian 3.1 box with the factory kernel, a RedHat 8.0 box with 2.4.18-24.8.0 (factory) kernel, and a RedHat 7.3 box with 2.4.25 (own-compiled) kernel. I get the anomaly in all instances.

I also tested if it exists in non-Linux (OpenBSD) environment (in which case I would have wondered if it is really a bug or rather my lack of knowledge), but OpenBSD worked the way I expected (and Linux' pivotroot(8)).

I am trying to build a box which would boot through the network and have its root directory through nfs (a'la ltsp.org), and it would provide shell access. But if things like "more" doesn't work, then it will be hard to use. Also, I don't know what else will be broken due to the problems with stderr.

Any ideas?

Vilmos