But security is only _one_ issue with "chroot()".
There are actually other uses for chroot(), like just creating a temporary
environment that gives another view of the system. It doesn't have to be
security-oriented per se, it can be used more to just have two independent
environments for working.
In some cases you'd _want_ to be able to move between environments.
Focusing on only security is silly: the whole basic design of UNIX is to
allow the user to do what he wants, not to make it harder to do "strange"
things.
For example, when Linux/alpha got ELF libraries, the first test-
environment was done under chroot. Not due to security at all, but in
order to install a new set of binaries without having to throw the old
(stable) set away. For that kind of chroot() use it would have been
positively detrimental to make chroot() do anything more than it does now.
Just as an example, with the current chroot() behaviour we can do stuff
like this:
- install a new test-gcc in a chroot environment
- compile programs _outside_ the chroot-environment with
change_root /gcc /usr/bin/gcc file.c -o file.o
and magically it all works correctly: the compiler (and all header files:
/usr/include etc) come from the chroot'ed environment, while the "file.c"
and "file.o" files are from _outside_ the chroot() environment exactly
because we do not change the current working directory.
In short, if you look at chroot() as only a security feature, you're
missing a lot of the implications of chroot(). I'm not so stupid that I'd
limit a very useful system call only because there are stupid programs out
there that can't do a "chdir()" at the same time as chroot.
So until somebody comes up with a GOOD argument for doing chdir()
automatically, this discussion is ended. Please think of ALL the
implications, and don't concentrate on just one small part of the system
(security).
As I said, security isn't trivial, and anybody who thinks he can get rid
of security holes by trivial fixes is very naive indeed. Sure, you can
make any system secure by disabling useful features, but that's just plain
stupid.
Just to show exactly HOW stupid this whole discussion is, here's inane
argument #1: "The suid/sgid bits are the main source of security holes, so
why don't we disable those altogether, and then we'll have a secure
system".
I'm not that stupid,
Linus