Mail Archives: djgpp-workers/1999/03/08/18:10:22
>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
- Raw text -