1228990Suqs$FreeBSD: releng/11.0/usr.sbin/cron/doc/CHANGES 228990 2011-12-30 10:58:14Z uqs $ 2228990Suqs-------- 3228990Suqs 42311SjkhVixie Cron Changes from V2 to V3 52311SjkhPaul Vixie 62311Sjkh29-Dec-1993 72311Sjkh 82311SjkhThe crontab command now conforms to POSIX 1003.2. This means that when you 92311Sjkhinstall it, if you have any "crontab" command lines floating around in shell 102311Sjkhscripts (such as /etc/rc or /etc/rc.local), you will need to change them. 112311Sjkh 122311SjkhI have integrated several changes made by BSDi for their BSD/386 operating 132311Sjkhsystem; these were offerred to me before I started consulting for them, so 142311Sjkhit is safe to say that they were intended for publication. Most notably, 152311Sjkhthe name of the cron daemon has changed from "crond" to "cron". This was 162311Sjkhdone for compatibility with 4.3BSD. Another change made for the same reason 172311Sjkhis the ability to read in an /etc/crontab file which has an extra field in 182311Sjkheach entry, between the time fields and the command. This field is a user 192311Sjkhname, and it permits the /etc/crontab command to contain commands which are 202311Sjkhto be run by any user on the system. /etc/crontab is not "installed" via 212311Sjkhthe crontab(1) command; it is automatically read at startup time and it will 222311Sjkhbe reread whenever it changes. 232311Sjkh 242311SjkhI also added a "-e" option to crontab(1). Nine people also sent me diffs 252311Sjkhto add this option, but I had already implemented it on my own. I actually 26228990Suqsreleased an interim version (V2.2, I think) for limited testing, and got a 272311Sjkhchance to fix a bad security bug in the "-e" option thanks to XXX. 282311Sjkh 292311SjkhThe daemon used to be extraordinarily sloppy in its use of file descriptors. 302311SjkhA heck of a lot of them were left open in spawned jobs, which caused problems 312311Sjkhfor the daemon and also caused problems with the spawned jobs if they were 322311Sjkhshell scripts since "sh" and "csh" have traditionally used hidden file 332311Sjkhdescriptors to pass information to subshells, and cron was causing them to 342311Sjkhthink they were subshells. If you had trouble with "sh" or "csh" scripts in 352311SjkhV2, chances are good that V3 will fix your problems. 362311Sjkh 372311SjkhAbout a dozen people have reminded me that I forgot to initialize 382311Sjkh"crontab_fd" in database.c. Keith Cantrell was the first, so he gets the 392311Sjkhpoint. 402311Sjkh 412311SjkhSteve Simmons reminded me that once an account has been deleted from the 422311Sjkhsystem, "crontab -u USER -d" will not work. My solution is to suggest to 432311Sjkhall of you that before you delete a user's account, you first delete that 442311Sjkhuser's crontab file if any. From cron's point of view, usernames can never 452311Sjkhbe treated as arbitrary strings. Either they are valid user names, or they 462311Sjkhare not. I will not make an exception for the "-d" case, for security 472311Sjkhreasons that I consider reasonable. It is trivial for a root user to delete 482311Sjkhthe entry by hand if necessary. 492311Sjkh 502311SjkhDan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of 512311Sjkhothers also reminded me of this, but Dan gets the point. I didn't fix it 522311Sjkhthere, since the real bug was that it should have been open in the parent. 532311Sjkh 542311SjkhPeter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in 552311Sjkhmisc.c. Hans Trompert actually told me first, but Peter sent the patch so 562311Sjkhhe gets the point. 572311Sjkh 582311SjkhRussell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c, 592311Sjkhwhich explains why a lot of other people complained that it wasn't using 602311Sjkhsyslog even when they configured it that way :-). Steve Simmons told me 612311Sjkhfirst, though, so he gets the point. 622311Sjkh 63228990SuqsAn interim version of the daemon tried to "stat" every file before 642311Sjkhexecuting it; this turned out to be a horribly bad idea since finding the 652311Sjkhname of a file from a shell command is a hard job (that's why we have 662311Sjkhshells, right?) I removed this bogus code. Dave Burgess gets the point. 672311Sjkh 682311SjkhDennis R. Conley sent a suggestion for MMDF systems, which I've added to the 692311Sjkhcomments in cron.h. 702311Sjkh 712311SjkhMike Heisler noted that I use comments in the CONVERSION file which are 722311Sjkhdocumented as illegal in the man pages. Thanks, Mike. 732311Sjkh 742311SjkhIrving Wolfe sent me some very cheerful changes for a NeXT system, but I 752311Sjkhconsider the system itself broken and I can't bring myself to #ifdef for 762311Sjkhsomething as screwed up as this system seems to be. However, various others 772311Sjkhdid send me smaller patches which appear to have cause cron to build and run 782311Sjkhcorrectly on (the latest) NeXT machines, with or without the "-posix" CFLAG. 792311SjkhIrving also asked for a per-job MAILTO, and this was finally added later when 802311SjkhI integrated the BSD/386 changes contributed by BSDi, and generalized some of 812311Sjkhthe parsing. 822311Sjkh 832311SjkhLots of folks complained that the autogenerated "Date:" header wasn't in 842311SjkhARPA format. I didn't understand this -- either folks will use Sendmail and 852311Sjkhnot generate a Date: at all (since Sendmail will do it), or folks will use 862311Sjkhsomething other than Sendmail which won't care about Date: formats. But 872311SjkhI've "fixed" it anyway... 882311Sjkh 892311SjkhSeveral people suggested that "*" should be able to take a "/step". One person 902311Sjkhsuggested that "N/step" ought to mean "N-last/step", but that's stretching things 912311Sjkha bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb 922311Sjkhsent in the first and most polite request for this feature. 932311Sjkh 942311SjkhAs with every release of Cron, BIND, and seemingly everything else I do, one 952311Sjkhuser stands out with the most critical but also the most useful analysis. 962311SjkhCron V3's high score belongs to Peter Holzer, who sent in the nicest looking 972311Sjkhpatch for the "%" interpretation problem and also helped me understand a 982311Sjkhtricky bit of badness in the "log_fd" problem. 992311Sjkh 1002311Sjkhagulbra@flode.nvg.unit.no wins the honors for being the first to point out the 1012311Sjkhnasty security hole in "crontab -r". 'Nuff said. 1022311Sjkh 1032311SjkhSeveral folks pointed out that log_it() needed to exist even if logging was 1042311Sjkhdisabled. Some day I will create a tool that will compile a subsystem with 1052311Sjkhevery possible combination and permutation of #ifdef options, but meanwhile 1062311Sjkhthanks to everybody. 1072311Sjkh 1082311Sjkhjob_runqueue() was using storage after freeing it, since Jordan told me back 1092311Sjkhin 1983 that C let you do that, and I believed him in 1986 when I wrote all 1102311Sjkhthis junk. Linux was the first to die from this error, and the Linux people 1112311Sjkhsent me the most amazing, um, collection of patches for this problem. Thanks 1122311Sjkhfor all the fish. 1132311Sjkh 1142311SjkhJeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's 1152311Sjkhversion of popen/pclose from the ftpd and hacked it to taste. We're safe now, 1162311Sjkhfrom this at least. 1172311Sjkh 1182311SjkhBranko Lankester sent me a very timely and helpful fix for a looming security 1192311Sjkhproblem in my "crontab -e" implementation. 1202311Sjkh 1212311Sjkh-------- 1222311Sjkh 1232311SjkhVixie Cron Changes from V1 to V2 1242311SjkhPaul Vixie 1252311Sjkh8-Feb-1988 1262311Sjkh 1272311SjkhMany changes were made in a rash of activity about six months ago, the exact 1282311Sjkhlist of which is no longer clear in my memory. I know that V1 used a file 1292311Sjkhcalled POKECRON in /usr/spool/cron to tell it that it was time to re-read 1302311Sjkhall the crontab files; V2 uses the modtime the crontab directory as a flag to 1312311Sjkhcheck out the crontab files; those whose modtime has changed will be re-read, 1322311Sjkhand the others left alone. Note that the crontab(1) command will do a utimes 1332311Sjkhcall to make sure the mtime of the dir changes, since the filename/inode will 1342311Sjkhoften remain the same after a replacement and the mtime wouldn't change in 1352311Sjkhthat case. 1362311Sjkh 1372311Sjkh8-Feb-88: made it possible to use much larger environment variable strings. 1382311Sjkh V1 allowed 100 characters; V2 allows 1000. This was needed for PATH 1392311Sjkh variables on some systems. Thanks to Toerless Eckert for this idea. 1402311Sjkh E-mail: UUCP: ...pyramid!fauern!faui10!eckert 1412311Sjkh 1422311Sjkh16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to 1432311Sjkh /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny}, 1442311Sjkh since the sysv naming for this depends on 'at' using the same 1452311Sjkh dir, which would be stupid (hint: use /usr/{lib,spool}/at). 1462311Sjkh 1472311Sjkh22-Feb-88: made it read the spool directory for crontabs and look each one 1482311Sjkh up using getpwnam() rather than reading all passwds with getpwent() 1492311Sjkh and trying to open each crontab. 1502311Sjkh 1512311Sjkh9-Dec-88: made it sync to :00 after the minute, makes cron predictable. 1522311Sjkh added logging to /var/cron/log. 1532311Sjkh 1542311Sjkh14-Apr-90: (actually, changes since December 1989) 1552311Sjkh fixed a number of bugs reported from the net and from John Gilmore. 1562311Sjkh added syslog per Keith Bostic. security features including not 1572311Sjkh being willing to run a command owned or writable by other than 1582311Sjkh the owner of the crontab 9not working well yet) 159