lkml.org 
[lkml]   [1996]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Glitch in sys_chroot()

On Fri, 15 Nov 1996, Jonathan Larmour wrote:
> At 20:29 14/11/96 -0500, Elliot Lee wrote:
> >What makes Linux's behaviour correct in your opinion? If it is supposed to
> >change the root directory, it should make sure the other parameters of the
> >process follow that root directory, including PWD.
>
> Indeed. In addition, the question is, what would it break?!

It would break all software that relies on the documented(!) property of
the chroot() call not to change directories.

> There's maybe more of a question if the cwd was within the chroot'ed area,
> e.g. cwd=/chroot/usr/bin and you do chroot /chroot fred. What I just
> proposed changes to /, whereas maybe its more sensible to do some more
> complex munging to work out that in this _particular_ case the cwd inode is
^^^^^^^^^^^^
> valid after all so don't touch it. The problem is, that to find this out we
> need to get the pathname associated with the cwd inode. The absence of
> directory hard links means it _should_ be unique, but there still isn't a
> mechanism I know to do this.

I believe this case is actually more than just a "particular" case.

Imagine for instance a ftp daemon doing a chdir to a guest users directory
that's inside the chrooted directory. If the proposed change would be made
to the Linux kernel, all of a sudden, starting from kernel version 2.1.X,
the daemon (running as root) would put you in the new root directory,
instead of your home directory.

This behaviour would be against the documented semantics. The new proposed
semantics would contradict what the manual page says and, as has been
seen, Linux would differ from all other Unixes in this respect. The new
semantics would perhaps guard us against sloppy code written by
programmers that are either too lazy to read the manual or otherwise don't
know what they are doing. On the other hand it would break code written by
programmers that *do* read the manual and do know what they are doing. If
you are writing programs that are to be run by root and are doing tricks
like chroot() you *should* know what you are doing.

> Does anyone know of such a mechanism? If not, could someone in the right
> place confirm the previous simple 2 line change will be added?

As can be seen from above, we should *not* change the directory if the cwd
is inside the new chroot environment. Now, you could change the directory
if cwd is outside the new root, but then things get messy and the two line
change won't be enough. You would have to find out both the absolute path
of the cwd and the new root, and check whether you are inside or outside.
IMHO, if you start doing this, it is against the whole philosophy of Unix.
Doing a chroot() just excludes the directories above the new root from
the file and directory name space. The cwd doesn't cease to exist if you
exclude it from the accessible name space. Also note that Unix does not
change directory if you remove the cwd.

Chroot() does one thing and chdir() does something else. Please let let it
stay that way, don't destroy the nice orthogonality by letting one stomp
on the other. Linux isn't a Microsoft operating system.

Johan Myreen
jem@iki.fi



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.071 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site