der Mouse writes:
>So, I was thinking, "why doesn't it presently?".  The only reason I can
>see is that if the user has (or can create) a writeable directory on
>the same filesystem as certain set-id executables, it becomes really

I believe the restriction was to prevent users creating their own
/etc/passwd etc.

>easy to leverage privilege.  It would also make escaping from a chroot
>jail easier.

By using r* back to the same box after gaining another user's id?
or did you have something else in mind?

>To address the first, I would suggest that processes, as well as mount
>points, have a "don't honor set-id bits" flag, and that non-root
>chroot() should set this flag.  To address the second, I suggest
>requiring that the path passed to chroot be an absolute path (in
>particular, "." is disallowed).

Marcus Ranum once described described using the simple fact that
chroot had been done to prevent all sorts of system calls
working.  It was specific to making it impossible for a 
chrooted process used for a firewall proxy to escape...

Your idea above sounds like a more general application of the
same idea - could be very handy.  I hate having to start
proxies as root _just_ so they can chroot(2).  Of course I don't
have source to all the OS's I build firewalls on :-)

--sjg