Date:	Tue, 23 Feb 1999 10:54:46 +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: patches for chroot
In-Reply-To:	<199902222318.XAA128862@out5.ibm.net>
Message-ID:	<Pine.SUN.3.91.990223104959.13846G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Mon, 22 Feb 1999, Mark E. wrote:

> +   }
> + /* If the path is absolute and a root path is set,
> +    then add the root path to the output. */
> +   else if (path[0] == '/' && _djgpp_root[0] != '\0')
> +   {
> +     char *root = _djgpp_root;
> +     char *abs_root = _djgpp_root;
> +     if (abs_root[0] && abs_root[1] == ':')
> +       abs_root += 2;
> +     if (strncmp (abs_root, "/dev/", 5) == 0)
> +     {
> +       _farnspokeb (o++, abs_root[5]);
> +       _farnspokeb (o++, ':');
> +       space -= 2;
> +       root = abs_root + 6;
> +     }
> +     for ( ; *root; root++)
> +     {
> +       _farnspokeb (o++, *root);
> +       space -= 1;
> +     }
>     }

I think once a non-trivial root is set, _put_path2 should disallow
absolute names which begin with a drive letter, including the /dev/x/
trick.

This might create contradictions between use of chroot in ftp client
and other restricted environments and its use in Bash, where somebody
might just want it to alleviate the pains of the drive-letter
braindamage, but not disable access to other drives.  But the
restriction is required in ftp clients, so I think we need some kind
of global flag variable to have both of these possibilities.

> + int
> + chroot (const char *path)
> + {
> +   if (path == NULL || *path == '\0')
> +   {
> +     _djgpp_root[0] = '\0';
> +     return 0;
> +   }

Is this how it works on Unix?  I don't see this in the man page on the
closest Unix box.  

If Unix doesn't behave that way, I think we should disallow NULL and
empty arguments.

I think in Unix the only way to return to the original root is with a call
to fchroot. 

> +   _fixpath (path, _djgpp_root);

I think you should see that the argument actually exists and is a
directory, before using it.  If it isn't, chroot should fail and set
errno as appropriate, instead of always succeeding.

Also, I think the implementation should cause the startup code to
access a certain environment variable (e.g. SYSROOT) and call chroot
with its value, and `chroot' should itself set that variable to the
current root.  That's because the current root should be inherited by
child programs, and the environment is the simplest way of having such
inheritance.  (If the implementation does use an environment variable,
it should be also mentioned in the docs.)  The environment variable
should also have a provision to specify the two flavors of the current
root (the restrictive and non-restrictive one, see above).

- Raw text -