It seems also that if you do not have read privileges on a program that you execute, it will not core dump. So another quick fix to this problem would be to take read permissions away on all your suids. humble On Tue, 7 Apr 1998, Paul Szabo wrote: > (Aleph1 and rusty: please ignore my previous, similar message...) > > rustyat_private wrote: > > Symlink problem in Digital Unix 4.0 ... > > Starting 2 suid root programs ... and killing them with -11 flag ... > > $ ln -s /.rhosts core > > $ ping somehost & > > [1] 1337 > > $ ping somehost & > > [2] 31337 > > $ kill -11 31337 > > $ kill -11 1337 > > [1] Segmentation fault /usr/sbin/ping somehost (core dumped) > > [2] +Segmentation fault /usr/sbin/ping somehost (core dumped) > > $ ls -l /.rhosts > > -rw------- 1 root system 385024 Mar 29 05:17 /.rhosts > > > > Other platforms: > > > > SunOs 4.1.x 5.5.x Doesn't work > > Linux 2.0.x Doesn't work > > Digital Unix 4.0d Doesn't work > > Others (note tested yet) > > I can reproduce this on Digital Unix 4.0B (OSF1 V4.0 564), with just one > setuid program: > > % unsetenv DISPLAY; xterm > > The only defence I can offer is to put the following line into the file > /sbin/rc3 (this is a sh script; most processes run by users are descendants > of this): > > ulimit -h -c 0 > > However this does not work for processes started from /etc/inittab: getty > (console and tty) logins. Instead of modifying /sbin/rc3, you could try > changing /etc/inittab to read something like: > > s3:3:wait:sh -c 'ulimit -h -c 0; /sbin/rc3 < /dev/console > /dev/console 2>&1' > cons:1234:respawn:sh -c 'ulimit -h -c 0; /usr/sbin/getty console console vt100' > > Obviously this prevents creating core files in all cases; fortunately our > users never need them to debug their own programs. > > Paul Szabo - System Manager // School of Mathematics and Statistics > pszat_private // University of Sydney, NSW 2006, Australia >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:48:15 PDT