Mail Archives: djgpp-workers/1999/02/24/04:16:52
On Tue, 23 Feb 1999, Nate Eldredge wrote:
> On Linux 2.2.1, it is. `chroot("/foo"); chroot("/bar")' ==
> `chroot("/foo/bar")'.
Thanks.
> This stands to reason, too, since AFAIK `chroot'
> is intended to be a trapdoor; once in the jail you cannot escape.
Not with `chroot', anyway. `fchroot' is the fire exit, as far as I
understand what the man pages tell.
Which means we need to pull some trickery, because `fchroot' accepts a
file descriptor, not a file name. That descriptor is supposed to come
from some call to `open' (before `chroot' was called), but DOS doesn't
allow to open a directory...
My first suggestion would be to modify `open' to ``succeed'' for
directories and return a file handle above 255 (DOS handles are all
below 255), and to record the directory pathname and its fake handle
in some internal structure which `fchroot' could access to find out
the name. I didn't think about this too much, but it seems that not
failing `open' for directories won't have any adverse effects, since
all other I/O functions, like `read', `lseek' etc. will fail with
EBADF automatically. If it turns out DOS does strange things for such
handles (e.g. because they wrap around in 8-bit-wide internal DOS
variables), we could add a test at the beginning of all related
functions, to reject them on our own.
An alternative would be to invent `_fchroot' or something which
accepts a pathname. Or maybe to have `fchroot' accept a second
argument, the pathname (Unix-compliant code shouldn't mind, unless
compiled with -Wall).
- Raw text -