crontab Daemon-from-Hell

[Robert J. Granvin]

>From private email I've received, a LOT of people's stomachs sunk to the floor
>when they read my posting, and they quickly discovered that a lot of files have
>been deleted by the "stock" uudemon.day script.  One person threatens to
>sue AT&T.

Lawsuits are fun.  Especially when you don't have a legal foot to
stand on.

I'm curious... On what grounds would such a lawsuit be made?

AT&T warrants that their software operates.  It doesn't warrant that
it operates well or even correctly.  By the way, this is the same way
that everyone warrants their software (read between the lines, you'll
see that the only time a warranty really falls apart is that if it
doesn't work at all).  The warranty is then amended with the
disclaimer that the distributor, author, producer or whoever else has
their fingers in it, does not warrant the software to be suitable for
any specific purpose, and (an important one here) that they are not
liable for any damage that arises from the use or inability to use
said software.

When you break all this down, you find that the source is only liable
to guarantee that the product works as advertised.  Beyond that, you
take full responsibility for it.  If the software fails, it is not
necessarily the manufacturers liability, since you agreed to the risk
of using it.

By utilizing group and user permissions even minimally, you can
protect yourself very well from rampant processes and even other
users.  This shouldn't be the alternative to solving any problem, but
it should also be utilized in general just for general safety and
minimal security.  While if something goes bonkers you may have to
reload some system software, but your own software is probably
secure.

>The point being: the "stock" uudemon.day is reprehensible and irresponsible

I wouldn't go to that extreme.  If so, then a _lot_ of software also
must be called reprehensible and irresponsible.  Stock uudemon.day
makes a simple assumption that can, but almost never, fails.  The
chances of you being bitten by it are pretty slim to none.  Of course,
you wouldn't want to be the statistic... :-)

However, I again bring up the point:  uudemon.day is and SHOULD be run
by uucp.  There are very few files on the system that can be deleted
by uucp, in general.  This isn't to say that any damage would be minor
or unnoticeable, however.  On the other hand, a person should never
make the assumption that running such a thing as root is a good idea.

>by not warning about pending deletion; my solution was an addition to
>uudemon.day that provides advance warning of the pending doom.  Variations on
>my original proposal include sending mail, but I still prefer my solution
>since EVERYONE (among the user community of a given system) is apprised of the
>situation and will be alerted to take action before it's too late.

I think we've sufficiently beaten this into the ground enough.

The solution is VERY simple.  Remove the `cd`, and make the find
reference an explicit path.  If the directory dies or goes away, the
find will fail, and nothing more will happen than your uucp mailfile
getting a note of the failure.

-- 
________Robert J. Granvin________   INTERNET: rjg at sialis.mn.org
____National Computer Systems____   CONFUSED: rjg%sialis.mn.org at shamash.cdc.com
__National Information Services__       UUCP: ...uunet!rosevax!sialis!rjg
                 "Exxon: Our gasoline contains no sea water"