There are two reasons why it shouldn't be done:
- vague tradition
- don't change things that aren't broken
There simply is no good reason to change it. Ergo, it doesn't get changed.
Now, I know that people think that it would be safer if chroot() changed
the pwd too, but I have a few arguments against that, namely:
- any program that is security conscious should NOT depend on behaviour
that is not portable or guaranteed. As such, if there is a program that
would be fixed by having chroot(2) do a chdir too, that program is
BROKEN, regardless of what the kernel does. Because the program would
be broken on (a) older Linux versions and (b) any other systems.
- even if chroot() _did_ do a chdir, it wouldn't automatically be 100%
secure. People who depend on chroot would _still_ have to know what
they are doing, and as such the "extra protection" offered by doing a
chdir() is pretty much worthless.
For example, if you do a script that does
chroot /ftp xxxxx
you should NOT automatically assume that the "xxxx" cannot get out of the
chrooted environment if a malicious person has access to "xxxx". Even if
you do a "chdir()", the malicious user could then do
do_script < /
and the "xxxx" program can do a "fchdir(0)".
Quote of the day: "Security is not trivial, and trying to fix security
problems with trivial fixes does not work".
Note: The chroot (8) program should probably get fixed, because it seems
other systems chroot-programs _do_ change the cwd, so in the case of
chroot (8) the "vague tradition" is reason enough to change it.
Note 2: I'm not dead set against doing a chdir() too in the kernel, but in
order to add it I'd really need a better reason than the ones I've seen so
far. "Vague tradition" is actually a pretty strong reason in itself, as
one of the design philosophies of Linux has been to be compatible: not
only with some paper standard (POSIX), but with "real life". So it
actually weighs more than you'd think..
Linus