Date: Thu, 25 Feb 1999 15:07:08 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT usa DOT net>
cc: djgpp-workers AT delorie DOT com
Subject: Re: updated chroot
In-Reply-To: <199902250602.GAA34258@out1.ibm.net>
Message-ID: <Pine.SUN.3.91.990225150526.19118A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com


On Thu, 25 Feb 1999, Mark E. wrote:

> char __djgpp_root [PATH_MAX+1] = { '\0' };
> int __djgpp_root_len = 0;
> unsigned int __chroot_flags = __CHROOT_UNIX_EMU_FLAG;

Static/global variables like these that cache information need to be
reinitialized if the program is restarted (like Emacs, after it dumps
its own image).  See the file _use_lfn.c from the library sources for
an example (look for code that uses the __bss_count variable).

>   if (unix_emu)
>   {
>     /* If the path returned from _fixpath isn't relative
>        to __djgpp_root, then the path is rejected. */
>     if (__djgpp_root_len != 0 && *buf != '/')
>     {
>       errno = EINVAL;
>       return -1;
>     }

I don't see this restriction in the man pages I can access.  It seems 
that a relative path is allowed.

>     /* Change the cwd like Unix versions do. */
>     if (chdir(buf) < 0)

I don't see this, either.  What Unix version describes this behavior?
I looked on SunOS 4.3 and Solaris 2.5, and they both say that chroot
doesn't affect the current directory.

What about fchroot?  It seems like in your implementation, all it
needs to do is to ignore its argument, momentarily set __chroot_flags
to disable Unix emulation, call chroot with an empty argument, restore
the flags, and return.

Thanks for working on this.