Re: Symlink problem (Tested only on a Digital Unix 4.0)

John McDonald (jmcdonal@UNF.EDU)
Tue, 07 Apr 1998 13:09:55 -0400

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...)
>
> rusty@mad.it 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
> psz@maths.usyd.edu.au // University of Sydney, NSW 2006, Australia
>