Xref: utzoo unix-pc.general:3023 comp.sys.att:6641 Path: utzoo!utgpu!watmath!uunet!shelby!agate!ucbvax!tut.cis.ohio-state.edu!unmvax!ncar!tank!shamash!sialis!rjg From: rjg@sialis.mn.org (Robert J. Granvin) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: crontab Daemon-from-Hell Message-ID: <1545@sialis.mn.org> Date: 9 Jun 89 02:16:27 GMT References: <19071@cup.portal.com> <14373@bfmny0.UUCP> <19196@cup.portal.com> Reply-To: rjg@sialis.mn.org (Robert J. Granvin) Followup-To: unix-pc.general Organization: Dr. Ho Laboratory and Day Care Center Lines: 67 >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@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg "Exxon: Our gasoline contains no sea water"