On Tue, 2002-10-22 at 11:42, Jesse Pollard wrote:
> On Saturday 19 October 2002 12:44 pm, Eric Buddington wrote:
> > On Tue, Oct 15, 2002 at 11:44:32PM -0700, Philippe Troin wrote:
> > > > Would it be reasonable to allow non-root processes to chroot(),
if the
> > > > chroot syscall also changed the cwd for non-root processes?
> > >
> > > No.
> > >
> > > fd = open("/", O_RDONLY);
> > > chroot("/tmp");
> > > fchdir(fd);
> > >
> > > and you're out of the chroot.
> >
> > I see. From my aesthetic, it would make sense for chroots to
'stack',
> > such that once a directory is made the root directory, its '..'
entry
> > *always* points to itself, even after another chroot(). That would
> > prevent the above break (you could be outside the new root, but you
> > still couldn't back out past the old root), though perhaps at an
> > unacceptable in complexity.
>
> That isn't relevent - the fchdir(fd) doesn't use a path. It doesn't
matter
> what is done to the ".." entry. fd is referring to an OPEN file id.
The
> chdir goes to the file id, bypassing any path name evaluation.
yes, but if the fd is within a chroot, then there will be a ".." above
that will be a chroot point, if you go into the orig chroot w an fd,
yea, you can go up to the "orig root" (aka the real /) from that fd.
Otherwise, you will be stopped once you hit a chroot point.
If you are in a chroot, and you can get chroot's to stack (as per I
described b4) then any fd you ever get will be locked in, as you wont be
able to use fchdir to jump out of all the chroot's and then ".." up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:59 EST