Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!tcdcs!dce.ie!ch
From: ch@dce.ie (Charles Bryant)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO doesn't sell UNIX
Message-ID: <1990Dec19.113102.10163@dce.ie>
Date: 19 Dec 90 11:31:02 GMT
References: <1990Dec1.223750.16286@NCoast.ORG> <275A9A50.3F3F@tct.uucp> <2341@tabbs.UUCP> <1990Dec08.224008.829@kithrup.COM>
Organization: Datacode Communications Ltd, Dublin, Ireland
Lines: 41

In article <1990Dec08.224008.829@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
>The luid stuff is mostly for accounting; I can come up with some
>circumstances where it would prevent some things from happening, but the
>bother is far more than it's worth.  (Try playing with a pseudo-user's
>crontab entry, for example.  Unless you want to futz with sending the
>appropriate signals and stuff to cron, you *can't*.)

While this is one reason I wrote oksetluid() (which forces the luid to
change, overriding the "security" if necessary), it is not too difficult
to get cron to reread the crontabs. Normally cron is started from /etc/rc.
Instead, start it from a line in the inittab. Then when you change a crontab
just kill cron and init will start another one. Of course cron orpans itself
(nasty feature), so you need to write /etc/pause (not too difficult :-),
and use the following in inittab:

cron:2:respawn:/etc/startcron >/dev/console 2>&1

where startcron is:

: use /bin/sh
# Start cron by removing an old FIFO and starting cron itself.
# We need this script because inittab commands are execed so there
# can't be more than one shell command.
# Aug 17 1990
rm -f /usr/lib/cron/FIFO
trap "" 2 3	# Don't let console quit and intr affect cron.
. /etc/TIMEZONE	# Probably don't need
/etc/cron
# Cron forks into the background so this script waits forever; kill the
# script when you kill cron, if you want to start a new cron.
exec /etc/pause


I must agree that the "C2 security" is a joke. In fact it probably reduces
the security of the system as its so complicated its a lot easier to believe
that a strang happening is a problem with the security system rather than
a break-in attempt.
-- 
Charles Bryant (ch@dce.ie)
--
/usr/ch/.signature: Block device required