but it is not a case of a process gaining root privs incorrectly; it is
the case of a legitimate setuid binary that is sneakily put into a chroot()ed
world with a hard link before the chroot() is done, and tricking it by the
chroot'ed world into looking in a bogus passwd file instead of the 
'right' one. the trouble is that this is a perfectly legitimate thing to do,
and the ancient ones chose to put the barrier of protection at the point of
chroot()ing, and declare that one needed to be root in order to do it.
this allows those who _have_ privileges to restrict those who havent got
them, which normally works in favor of sysadmins. 
I don't see a problem with only root being andle to chroot. it is always 
possible with little effort to provide users with a setuid binary that will
chroot and give them a shell in the chroot'ed world, and also hopefully
do some checking to validate that theyre chrooting into a safe world. 
Allowing only root to do things in unix does not mean that nobody else 
can do them, it means that people can choose what things to give to users
as they see fit at their site. Think of all the variations on the /etc/passwd
swap that we have been discussing, and all of the bait-&-switch tricks that
allowing any old user to chroot arbitrarily can cause. Then think of all
the uses for users chrooting at will, and i think only a few very special
cases will not be served by someone just putting a setuid binary that can
chroot for you. and, speaking of that, such a command already exists, and 
it is called chroot. Modifying this command for a local site's needs to allow
it to be safely run setuid is up to individual sites to do as they see 
fit, typically this would involve either a priori or at runtime verification
that there werent e.g. setuid root binaries in the chroot()ed tree, or 
similar hazards. 

Isildur


On Mon, 27 Jan 2003, mouss wrote:
> ahem??? if a process can become root while it was not, then there's
> an enor-mouss problem somewhere!
> 
> >This falls into the same category of "Under what conditions is it safe to
> >point a loaded gun at oneself?", really.
> 
> If it was me, I'd allow anyone to chroot, as I see no design rationale for 
> linking
> chroot with access control. It's like in real life, being able to drink 
> beer doesn't
> give you the right to enter a bar....
> 
>