delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/02/24/04:16:52

Date: Wed, 24 Feb 1999 11:13:26 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Nate Eldredge <nate AT cartsys DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: patches for chroot
In-Reply-To: <36D3287A.B400FF70@cartsys.com>
Message-ID: <Pine.SUN.3.91.990224111302.22838H-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019