Date: Tue, 9 Mar 1999 12:13:12 +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: chroot patches v4
In-Reply-To: <199903082310.XAA53896@out1.ibm.net>
Message-ID: <Pine.SUN.3.91.990309121252.7248T-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 8 Mar 1999, Mark E. wrote:

> > 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?

Both ;-)

Sorry, I was unclear in the last statement.  The argument is
interpreted relative to the current root, IF IT BEGINS WITH A SLASH.
The second statement above referred only to such names, but I should
have told that explicitly.

> > 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.

Okay, then I'm sorry I've brought up a non-issue.

> 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.

Well, actually, that's what I had in mind ;-).  Of course, there are
half a dozen other possible solutions, it's for you to choose.