Date: Wed, 24 Feb 1999 11:13:26 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Nate Eldredge cc: djgpp-workers AT delorie DOT com Subject: Re: patches for chroot In-Reply-To: <36D3287A.B400FF70@cartsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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).