Message-Id: <199903082310.XAA53896@out1.ibm.net>
From: "Mark E." <snowball3 AT usa DOT net>
To: djgpp-workers AT delorie DOT com
Date: Mon, 8 Mar 1999 18:10:03 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: chroot patches v4
References: <199903041811 DOT SAA92588 AT out5 DOT ibm DOT net>
In-reply-to: <Pine.SUN.3.91.990308113504.23421W-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Reply-To: djgpp-workers AT delorie DOT com

>Unfortunately, I'm afraid I need to be the Bad Guy again ;-)
No problem.

> I don't see such interpretation in the Unix man pages.  Relative file
> names are allowed and are interpreted as usual: relative to cwd.
> 
> > +   if (unix_emu)
> > +   {
> > +     /* If a root directory already exists, the new root directory
> > +        must be relative to the existing root directory.
> > +        If not, then reject the path. */
> > +     if (__djgpp_root_len > 0 && *buf != '/')
> > +     {
> > +       errno = EACCES;
> > +       return -1;
> > +     }
> 
> Nate tried on Linux and said that the argument passed to `chroot' is
> always interpreted as relative to the current root.  However, your
> implementation calls `_fixpath' too early, and thus deviates from this
> behavior.

First you say arguments that are relative filenames are relative to 
the cwd, then you say all arguments are relative to the current root. 
Which is it?

I'm not sure I agree about _fixpath being called too early. _fixpath 
will delete the portion of the path matching the root and replace it 
with '/'. So if a replacement root path isn't relative to the current 
root, then the output of _fixpath will not begin with '/' and so path 
will be rejected.

> For example, if the current root is "c:/foo" and `chroot' is called
> with "/foo/bar/baz", then `chroot' will allow it (I think; I didn't
> actually try this) because it generates "c:/foo/bar/baz" and then
> removes "c:/foo" from it.

That's not quite how it works. I had to trace through with RHIDE 
just to make sure. Let's assume that "c:/foo/bar/baz" exists. 'chroot' 
will call _fixpath with '/foo/bar/baz'. _fixpath then calls _put_path. 
_put_path sees that the first character is '/' and tacks on the root to 
the output. The result is "c:/foo/foo/bar/baz'. _fixpath then reads 
back the output and continues its work. At the end, _fixpath then 
deletes 'c:/foo' to give us '/foo/bar/baz', our original argument. The 
output is then given to access() which calls _put_path which again 
sees the '/' and tacks on the root. access() then does its work with 
the result being that access returns with a failure result since 
there is no 'c:/foo/foo/bar/baz'. (Whew!)

> `chroot' must be stubbed (see <libc/stubs.h>).  I suggest
> to use `stricmp' instead of `strnicmp' and `putenv' instead of
> `setenv', since the replacements are already stubbed, and to add the
> necessary code for the replacements to work.
> 

Substituting stricmp for strnicmp is not a good option, at least not 
without some hackish code to temporarily stick in a '\0' in the 
string I'm checking, do the comparison, and then restore the 
character.

> the Unix emulation flag is set, otherwise ``chdir ("c:/foo")'' and
> such likes will defeat the purpose of this feature.  The simplest way
> to do that is to prepend the current root to the argument, if the
> latter starts with a drive letter.
> 

I've already modified chdir to prevent this, but then I'd have to 
modify many more functions. It probably is easier to prevent what 
you note in one place.

Mark