1*3df5ecacSUlrich Spörlein$FreeBSD$ 2*3df5ecacSUlrich Spörlein-------- 3*3df5ecacSUlrich Spörlein 484f33deaSJordan K. HubbardVixie Cron Changes from V2 to V3 584f33deaSJordan K. HubbardPaul Vixie 684f33deaSJordan K. Hubbard29-Dec-1993 784f33deaSJordan K. Hubbard 884f33deaSJordan K. HubbardThe crontab command now conforms to POSIX 1003.2. This means that when you 984f33deaSJordan K. Hubbardinstall it, if you have any "crontab" command lines floating around in shell 1084f33deaSJordan K. Hubbardscripts (such as /etc/rc or /etc/rc.local), you will need to change them. 1184f33deaSJordan K. Hubbard 1284f33deaSJordan K. HubbardI have integrated several changes made by BSDi for their BSD/386 operating 1384f33deaSJordan K. Hubbardsystem; these were offerred to me before I started consulting for them, so 1484f33deaSJordan K. Hubbardit is safe to say that they were intended for publication. Most notably, 1584f33deaSJordan K. Hubbardthe name of the cron daemon has changed from "crond" to "cron". This was 1684f33deaSJordan K. Hubbarddone for compatibility with 4.3BSD. Another change made for the same reason 1784f33deaSJordan K. Hubbardis the ability to read in an /etc/crontab file which has an extra field in 1884f33deaSJordan K. Hubbardeach entry, between the time fields and the command. This field is a user 1984f33deaSJordan K. Hubbardname, and it permits the /etc/crontab command to contain commands which are 2084f33deaSJordan K. Hubbardto be run by any user on the system. /etc/crontab is not "installed" via 2184f33deaSJordan K. Hubbardthe crontab(1) command; it is automatically read at startup time and it will 2284f33deaSJordan K. Hubbardbe reread whenever it changes. 2384f33deaSJordan K. Hubbard 2484f33deaSJordan K. HubbardI also added a "-e" option to crontab(1). Nine people also sent me diffs 2584f33deaSJordan K. Hubbardto add this option, but I had already implemented it on my own. I actually 26*3df5ecacSUlrich Spörleinreleased an interim version (V2.2, I think) for limited testing, and got a 2784f33deaSJordan K. Hubbardchance to fix a bad security bug in the "-e" option thanks to XXX. 2884f33deaSJordan K. Hubbard 2984f33deaSJordan K. HubbardThe daemon used to be extraordinarily sloppy in its use of file descriptors. 3084f33deaSJordan K. HubbardA heck of a lot of them were left open in spawned jobs, which caused problems 3184f33deaSJordan K. Hubbardfor the daemon and also caused problems with the spawned jobs if they were 3284f33deaSJordan K. Hubbardshell scripts since "sh" and "csh" have traditionally used hidden file 3384f33deaSJordan K. Hubbarddescriptors to pass information to subshells, and cron was causing them to 3484f33deaSJordan K. Hubbardthink they were subshells. If you had trouble with "sh" or "csh" scripts in 3584f33deaSJordan K. HubbardV2, chances are good that V3 will fix your problems. 3684f33deaSJordan K. Hubbard 3784f33deaSJordan K. HubbardAbout a dozen people have reminded me that I forgot to initialize 3884f33deaSJordan K. Hubbard"crontab_fd" in database.c. Keith Cantrell was the first, so he gets the 3984f33deaSJordan K. Hubbardpoint. 4084f33deaSJordan K. Hubbard 4184f33deaSJordan K. HubbardSteve Simmons reminded me that once an account has been deleted from the 4284f33deaSJordan K. Hubbardsystem, "crontab -u USER -d" will not work. My solution is to suggest to 4384f33deaSJordan K. Hubbardall of you that before you delete a user's account, you first delete that 4484f33deaSJordan K. Hubbarduser's crontab file if any. From cron's point of view, usernames can never 4584f33deaSJordan K. Hubbardbe treated as arbitrary strings. Either they are valid user names, or they 4684f33deaSJordan K. Hubbardare not. I will not make an exception for the "-d" case, for security 4784f33deaSJordan K. Hubbardreasons that I consider reasonable. It is trivial for a root user to delete 4884f33deaSJordan K. Hubbardthe entry by hand if necessary. 4984f33deaSJordan K. Hubbard 5084f33deaSJordan K. HubbardDan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of 5184f33deaSJordan K. Hubbardothers also reminded me of this, but Dan gets the point. I didn't fix it 5284f33deaSJordan K. Hubbardthere, since the real bug was that it should have been open in the parent. 5384f33deaSJordan K. Hubbard 5484f33deaSJordan K. HubbardPeter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in 5584f33deaSJordan K. Hubbardmisc.c. Hans Trompert actually told me first, but Peter sent the patch so 5684f33deaSJordan K. Hubbardhe gets the point. 5784f33deaSJordan K. Hubbard 5884f33deaSJordan K. HubbardRussell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c, 5984f33deaSJordan K. Hubbardwhich explains why a lot of other people complained that it wasn't using 6084f33deaSJordan K. Hubbardsyslog even when they configured it that way :-). Steve Simmons told me 6184f33deaSJordan K. Hubbardfirst, though, so he gets the point. 6284f33deaSJordan K. Hubbard 63*3df5ecacSUlrich SpörleinAn interim version of the daemon tried to "stat" every file before 6484f33deaSJordan K. Hubbardexecuting it; this turned out to be a horribly bad idea since finding the 6584f33deaSJordan K. Hubbardname of a file from a shell command is a hard job (that's why we have 6684f33deaSJordan K. Hubbardshells, right?) I removed this bogus code. Dave Burgess gets the point. 6784f33deaSJordan K. Hubbard 6884f33deaSJordan K. HubbardDennis R. Conley sent a suggestion for MMDF systems, which I've added to the 6984f33deaSJordan K. Hubbardcomments in cron.h. 7084f33deaSJordan K. Hubbard 7184f33deaSJordan K. HubbardMike Heisler noted that I use comments in the CONVERSION file which are 7284f33deaSJordan K. Hubbarddocumented as illegal in the man pages. Thanks, Mike. 7384f33deaSJordan K. Hubbard 7484f33deaSJordan K. HubbardIrving Wolfe sent me some very cheerful changes for a NeXT system, but I 7584f33deaSJordan K. Hubbardconsider the system itself broken and I can't bring myself to #ifdef for 7684f33deaSJordan K. Hubbardsomething as screwed up as this system seems to be. However, various others 7784f33deaSJordan K. Hubbarddid send me smaller patches which appear to have cause cron to build and run 7884f33deaSJordan K. Hubbardcorrectly on (the latest) NeXT machines, with or without the "-posix" CFLAG. 7984f33deaSJordan K. HubbardIrving also asked for a per-job MAILTO, and this was finally added later when 8084f33deaSJordan K. HubbardI integrated the BSD/386 changes contributed by BSDi, and generalized some of 8184f33deaSJordan K. Hubbardthe parsing. 8284f33deaSJordan K. Hubbard 8384f33deaSJordan K. HubbardLots of folks complained that the autogenerated "Date:" header wasn't in 8484f33deaSJordan K. HubbardARPA format. I didn't understand this -- either folks will use Sendmail and 8584f33deaSJordan K. Hubbardnot generate a Date: at all (since Sendmail will do it), or folks will use 8684f33deaSJordan K. Hubbardsomething other than Sendmail which won't care about Date: formats. But 8784f33deaSJordan K. HubbardI've "fixed" it anyway... 8884f33deaSJordan K. Hubbard 8984f33deaSJordan K. HubbardSeveral people suggested that "*" should be able to take a "/step". One person 9084f33deaSJordan K. Hubbardsuggested that "N/step" ought to mean "N-last/step", but that's stretching things 9184f33deaSJordan K. Hubbarda bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb 9284f33deaSJordan K. Hubbardsent in the first and most polite request for this feature. 9384f33deaSJordan K. Hubbard 9484f33deaSJordan K. HubbardAs with every release of Cron, BIND, and seemingly everything else I do, one 9584f33deaSJordan K. Hubbarduser stands out with the most critical but also the most useful analysis. 9684f33deaSJordan K. HubbardCron V3's high score belongs to Peter Holzer, who sent in the nicest looking 9784f33deaSJordan K. Hubbardpatch for the "%" interpretation problem and also helped me understand a 9884f33deaSJordan K. Hubbardtricky bit of badness in the "log_fd" problem. 9984f33deaSJordan K. Hubbard 10084f33deaSJordan K. Hubbardagulbra@flode.nvg.unit.no wins the honors for being the first to point out the 10184f33deaSJordan K. Hubbardnasty security hole in "crontab -r". 'Nuff said. 10284f33deaSJordan K. Hubbard 10384f33deaSJordan K. HubbardSeveral folks pointed out that log_it() needed to exist even if logging was 10484f33deaSJordan K. Hubbarddisabled. Some day I will create a tool that will compile a subsystem with 10584f33deaSJordan K. Hubbardevery possible combination and permutation of #ifdef options, but meanwhile 10684f33deaSJordan K. Hubbardthanks to everybody. 10784f33deaSJordan K. Hubbard 10884f33deaSJordan K. Hubbardjob_runqueue() was using storage after freeing it, since Jordan told me back 10984f33deaSJordan K. Hubbardin 1983 that C let you do that, and I believed him in 1986 when I wrote all 11084f33deaSJordan K. Hubbardthis junk. Linux was the first to die from this error, and the Linux people 11184f33deaSJordan K. Hubbardsent me the most amazing, um, collection of patches for this problem. Thanks 11284f33deaSJordan K. Hubbardfor all the fish. 11384f33deaSJordan K. Hubbard 11484f33deaSJordan K. HubbardJeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's 11584f33deaSJordan K. Hubbardversion of popen/pclose from the ftpd and hacked it to taste. We're safe now, 11684f33deaSJordan K. Hubbardfrom this at least. 11784f33deaSJordan K. Hubbard 11884f33deaSJordan K. HubbardBranko Lankester sent me a very timely and helpful fix for a looming security 11984f33deaSJordan K. Hubbardproblem in my "crontab -e" implementation. 12084f33deaSJordan K. Hubbard 12184f33deaSJordan K. Hubbard-------- 12284f33deaSJordan K. Hubbard 12384f33deaSJordan K. HubbardVixie Cron Changes from V1 to V2 12484f33deaSJordan K. HubbardPaul Vixie 12584f33deaSJordan K. Hubbard8-Feb-1988 12684f33deaSJordan K. Hubbard 12784f33deaSJordan K. HubbardMany changes were made in a rash of activity about six months ago, the exact 12884f33deaSJordan K. Hubbardlist of which is no longer clear in my memory. I know that V1 used a file 12984f33deaSJordan K. Hubbardcalled POKECRON in /usr/spool/cron to tell it that it was time to re-read 13084f33deaSJordan K. Hubbardall the crontab files; V2 uses the modtime the crontab directory as a flag to 13184f33deaSJordan K. Hubbardcheck out the crontab files; those whose modtime has changed will be re-read, 13284f33deaSJordan K. Hubbardand the others left alone. Note that the crontab(1) command will do a utimes 13384f33deaSJordan K. Hubbardcall to make sure the mtime of the dir changes, since the filename/inode will 13484f33deaSJordan K. Hubbardoften remain the same after a replacement and the mtime wouldn't change in 13584f33deaSJordan K. Hubbardthat case. 13684f33deaSJordan K. Hubbard 13784f33deaSJordan K. Hubbard8-Feb-88: made it possible to use much larger environment variable strings. 13884f33deaSJordan K. Hubbard V1 allowed 100 characters; V2 allows 1000. This was needed for PATH 13984f33deaSJordan K. Hubbard variables on some systems. Thanks to Toerless Eckert for this idea. 14084f33deaSJordan K. Hubbard E-mail: UUCP: ...pyramid!fauern!faui10!eckert 14184f33deaSJordan K. Hubbard 14284f33deaSJordan K. Hubbard16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to 14384f33deaSJordan K. Hubbard /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny}, 14484f33deaSJordan K. Hubbard since the sysv naming for this depends on 'at' using the same 14584f33deaSJordan K. Hubbard dir, which would be stupid (hint: use /usr/{lib,spool}/at). 14684f33deaSJordan K. Hubbard 14784f33deaSJordan K. Hubbard22-Feb-88: made it read the spool directory for crontabs and look each one 14884f33deaSJordan K. Hubbard up using getpwnam() rather than reading all passwds with getpwent() 14984f33deaSJordan K. Hubbard and trying to open each crontab. 15084f33deaSJordan K. Hubbard 15184f33deaSJordan K. Hubbard9-Dec-88: made it sync to :00 after the minute, makes cron predictable. 15284f33deaSJordan K. Hubbard added logging to /var/cron/log. 15384f33deaSJordan K. Hubbard 15484f33deaSJordan K. Hubbard14-Apr-90: (actually, changes since December 1989) 15584f33deaSJordan K. Hubbard fixed a number of bugs reported from the net and from John Gilmore. 15684f33deaSJordan K. Hubbard added syslog per Keith Bostic. security features including not 15784f33deaSJordan K. Hubbard being willing to run a command owned or writable by other than 15884f33deaSJordan K. Hubbard the owner of the crontab 9not working well yet) 159