1*86d7f5d3SJohn MarinoVixie Cron Changes from V2 to V3 2*86d7f5d3SJohn MarinoPaul Vixie 3*86d7f5d3SJohn Marino29-Dec-1993 4*86d7f5d3SJohn Marino 5*86d7f5d3SJohn MarinoThe crontab command now conforms to POSIX 1003.2. This means that when you 6*86d7f5d3SJohn Marinoinstall it, if you have any "crontab" command lines floating around in shell 7*86d7f5d3SJohn Marinoscripts (such as /etc/rc or /etc/rc.local), you will need to change them. 8*86d7f5d3SJohn Marino 9*86d7f5d3SJohn MarinoI have integrated several changes made by BSDi for their BSD/386 operating 10*86d7f5d3SJohn Marinosystem; these were offerred to me before I started consulting for them, so 11*86d7f5d3SJohn Marinoit is safe to say that they were intended for publication. Most notably, 12*86d7f5d3SJohn Marinothe name of the cron daemon has changed from "crond" to "cron". This was 13*86d7f5d3SJohn Marinodone for compatibility with 4.3BSD. Another change made for the same reason 14*86d7f5d3SJohn Marinois the ability to read in an /etc/crontab file which has an extra field in 15*86d7f5d3SJohn Marinoeach entry, between the time fields and the command. This field is a user 16*86d7f5d3SJohn Marinoname, and it permits the /etc/crontab command to contain commands which are 17*86d7f5d3SJohn Marinoto be run by any user on the system. /etc/crontab is not "installed" via 18*86d7f5d3SJohn Marinothe crontab(1) command; it is automatically read at startup time and it will 19*86d7f5d3SJohn Marinobe reread whenever it changes. 20*86d7f5d3SJohn Marino 21*86d7f5d3SJohn MarinoI also added a "-e" option to crontab(1). Nine people also sent me diffs 22*86d7f5d3SJohn Marinoto add this option, but I had already implemented it on my own. I actually 23*86d7f5d3SJohn Marinoreleased an interrim version (V2.2, I think) for limited testing, and got a 24*86d7f5d3SJohn Marinochance to fix a bad security bug in the "-e" option thanks to XXX. 25*86d7f5d3SJohn Marino 26*86d7f5d3SJohn MarinoThe daemon used to be extraordinarily sloppy in its use of file descriptors. 27*86d7f5d3SJohn MarinoA heck of a lot of them were left open in spawned jobs, which caused problems 28*86d7f5d3SJohn Marinofor the daemon and also caused problems with the spawned jobs if they were 29*86d7f5d3SJohn Marinoshell scripts since "sh" and "csh" have traditionally used hidden file 30*86d7f5d3SJohn Marinodescriptors to pass information to subshells, and cron was causing them to 31*86d7f5d3SJohn Marinothink they were subshells. If you had trouble with "sh" or "csh" scripts in 32*86d7f5d3SJohn MarinoV2, chances are good that V3 will fix your problems. 33*86d7f5d3SJohn Marino 34*86d7f5d3SJohn MarinoAbout a dozen people have reminded me that I forgot to initialize 35*86d7f5d3SJohn Marino"crontab_fd" in database.c. Keith Cantrell was the first, so he gets the 36*86d7f5d3SJohn Marinopoint. 37*86d7f5d3SJohn Marino 38*86d7f5d3SJohn MarinoSteve Simmons reminded me that once an account has been deleted from the 39*86d7f5d3SJohn Marinosystem, "crontab -u USER -d" will not work. My solution is to suggest to 40*86d7f5d3SJohn Marinoall of you that before you delete a user's account, you first delete that 41*86d7f5d3SJohn Marinouser's crontab file if any. From cron's point of view, usernames can never 42*86d7f5d3SJohn Marinobe treated as arbitrary strings. Either they are valid user names, or they 43*86d7f5d3SJohn Marinoare not. I will not make an exception for the "-d" case, for security 44*86d7f5d3SJohn Marinoreasons that I consider reasonable. It is trivial for a root user to delete 45*86d7f5d3SJohn Marinothe entry by hand if necessary. 46*86d7f5d3SJohn Marino 47*86d7f5d3SJohn MarinoDan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of 48*86d7f5d3SJohn Marinoothers also reminded me of this, but Dan gets the point. I didn't fix it 49*86d7f5d3SJohn Marinothere, since the real bug was that it should have been open in the parent. 50*86d7f5d3SJohn Marino 51*86d7f5d3SJohn MarinoPeter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in 52*86d7f5d3SJohn Marinomisc.c. Hans Trompert actually told me first, but Peter sent the patch so 53*86d7f5d3SJohn Marinohe gets the point. 54*86d7f5d3SJohn Marino 55*86d7f5d3SJohn MarinoRussell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c, 56*86d7f5d3SJohn Marinowhich explains why a lot of other people complained that it wasn't using 57*86d7f5d3SJohn Marinosyslog even when they configured it that way :-). Steve Simmons told me 58*86d7f5d3SJohn Marinofirst, though, so he gets the point. 59*86d7f5d3SJohn Marino 60*86d7f5d3SJohn MarinoAn interrim version of the daemon tried to "stat" every file before 61*86d7f5d3SJohn Marinoexecuting it; this turned out to be a horribly bad idea since finding the 62*86d7f5d3SJohn Marinoname of a file from a shell command is a hard job (that's why we have 63*86d7f5d3SJohn Marinoshells, right?) I removed this bogus code. Dave Burgess gets the point. 64*86d7f5d3SJohn Marino 65*86d7f5d3SJohn MarinoDennis R. Conley sent a suggestion for MMDF systems, which I've added to the 66*86d7f5d3SJohn Marinocomments in cron.h. 67*86d7f5d3SJohn Marino 68*86d7f5d3SJohn MarinoMike Heisler noted that I use comments in the CONVERSION file which are 69*86d7f5d3SJohn Marinodocumented as illegal in the man pages. Thanks, Mike. 70*86d7f5d3SJohn Marino 71*86d7f5d3SJohn MarinoIrving Wolfe sent me some very cheerful changes for a NeXT system, but I 72*86d7f5d3SJohn Marinoconsider the system itself broken and I can't bring myself to #ifdef for 73*86d7f5d3SJohn Marinosomething as screwed up as this system seems to be. However, various others 74*86d7f5d3SJohn Marinodid send me smaller patches which appear to have cause cron to build and run 75*86d7f5d3SJohn Marinocorrectly on (the latest) NeXT machines, with or without the "-posix" CFLAG. 76*86d7f5d3SJohn MarinoIrving also asked for a per-job MAILTO, and this was finally added later when 77*86d7f5d3SJohn MarinoI integrated the BSD/386 changes contributed by BSDi, and generalized some of 78*86d7f5d3SJohn Marinothe parsing. 79*86d7f5d3SJohn Marino 80*86d7f5d3SJohn MarinoLots of folks complained that the autogenerated "Date:" header wasn't in 81*86d7f5d3SJohn MarinoARPA format. I didn't understand this -- either folks will use Sendmail and 82*86d7f5d3SJohn Marinonot generate a Date: at all (since Sendmail will do it), or folks will use 83*86d7f5d3SJohn Marinosomething other than Sendmail which won't care about Date: formats. But 84*86d7f5d3SJohn MarinoI've "fixed" it anyway... 85*86d7f5d3SJohn Marino 86*86d7f5d3SJohn MarinoSeveral people suggested that "*" should be able to take a "/step". One person 87*86d7f5d3SJohn Marinosuggested that "N/step" ought to mean "N-last/step", but that's stretching things 88*86d7f5d3SJohn Marinoa bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb 89*86d7f5d3SJohn Marinosent in the first and most polite request for this feature. 90*86d7f5d3SJohn Marino 91*86d7f5d3SJohn MarinoAs with every release of Cron, BIND, and seemingly everything else I do, one 92*86d7f5d3SJohn Marinouser stands out with the most critical but also the most useful analysis. 93*86d7f5d3SJohn MarinoCron V3's high score belongs to Peter Holzer, who sent in the nicest looking 94*86d7f5d3SJohn Marinopatch for the "%" interpretation problem and also helped me understand a 95*86d7f5d3SJohn Marinotricky bit of badness in the "log_fd" problem. 96*86d7f5d3SJohn Marino 97*86d7f5d3SJohn Marinoagulbra@flode.nvg.unit.no wins the honors for being the first to point out the 98*86d7f5d3SJohn Marinonasty security hole in "crontab -r". 'Nuff said. 99*86d7f5d3SJohn Marino 100*86d7f5d3SJohn MarinoSeveral folks pointed out that log_it() needed to exist even if logging was 101*86d7f5d3SJohn Marinodisabled. Some day I will create a tool that will compile a subsystem with 102*86d7f5d3SJohn Marinoevery possible combination and permutation of #ifdef options, but meanwhile 103*86d7f5d3SJohn Marinothanks to everybody. 104*86d7f5d3SJohn Marino 105*86d7f5d3SJohn Marinojob_runqueue() was using storage after freeing it, since Jordan told me back 106*86d7f5d3SJohn Marinoin 1983 that C let you do that, and I believed him in 1986 when I wrote all 107*86d7f5d3SJohn Marinothis junk. Linux was the first to die from this error, and the Linux people 108*86d7f5d3SJohn Marinosent me the most amazing, um, collection of patches for this problem. Thanks 109*86d7f5d3SJohn Marinofor all the fish. 110*86d7f5d3SJohn Marino 111*86d7f5d3SJohn MarinoJeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's 112*86d7f5d3SJohn Marinoversion of popen/pclose from the ftpd and hacked it to taste. We're safe now, 113*86d7f5d3SJohn Marinofrom this at least. 114*86d7f5d3SJohn Marino 115*86d7f5d3SJohn MarinoBranko Lankester sent me a very timely and helpful fix for a looming security 116*86d7f5d3SJohn Marinoproblem in my "crontab -e" implementation. 117*86d7f5d3SJohn Marino 118*86d7f5d3SJohn Marino-------- 119*86d7f5d3SJohn Marino 120*86d7f5d3SJohn MarinoVixie Cron Changes from V1 to V2 121*86d7f5d3SJohn MarinoPaul Vixie 122*86d7f5d3SJohn Marino8-Feb-1988 123*86d7f5d3SJohn Marino 124*86d7f5d3SJohn MarinoMany changes were made in a rash of activity about six months ago, the exact 125*86d7f5d3SJohn Marinolist of which is no longer clear in my memory. I know that V1 used a file 126*86d7f5d3SJohn Marinocalled POKECRON in /usr/spool/cron to tell it that it was time to re-read 127*86d7f5d3SJohn Marinoall the crontab files; V2 uses the modtime the crontab directory as a flag to 128*86d7f5d3SJohn Marinocheck out the crontab files; those whose modtime has changed will be re-read, 129*86d7f5d3SJohn Marinoand the others left alone. Note that the crontab(1) command will do a utimes 130*86d7f5d3SJohn Marinocall to make sure the mtime of the dir changes, since the filename/inode will 131*86d7f5d3SJohn Marinooften remain the same after a replacement and the mtime wouldn't change in 132*86d7f5d3SJohn Marinothat case. 133*86d7f5d3SJohn Marino 134*86d7f5d3SJohn Marino8-Feb-88: made it possible to use much larger environment variable strings. 135*86d7f5d3SJohn Marino V1 allowed 100 characters; V2 allows 1000. This was needed for PATH 136*86d7f5d3SJohn Marino variables on some systems. Thanks to Toerless Eckert for this idea. 137*86d7f5d3SJohn Marino E-mail: UUCP: ...pyramid!fauern!faui10!eckert 138*86d7f5d3SJohn Marino 139*86d7f5d3SJohn Marino16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to 140*86d7f5d3SJohn Marino /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny}, 141*86d7f5d3SJohn Marino since the sysv naming for this depends on 'at' using the same 142*86d7f5d3SJohn Marino dir, which would be stupid (hint: use /usr/{lib,spool}/at). 143*86d7f5d3SJohn Marino 144*86d7f5d3SJohn Marino22-Feb-88: made it read the spool directory for crontabs and look each one 145*86d7f5d3SJohn Marino up using getpwnam() rather than reading all passwds with getpwent() 146*86d7f5d3SJohn Marino and trying to open each crontab. 147*86d7f5d3SJohn Marino 148*86d7f5d3SJohn Marino9-Dec-88: made it sync to :00 after the minute, makes cron predictable. 149*86d7f5d3SJohn Marino added logging to /var/cron/log. 150*86d7f5d3SJohn Marino 151*86d7f5d3SJohn Marino14-Apr-90: (actually, changes since December 1989) 152*86d7f5d3SJohn Marino fixed a number of bugs reported from the net and from John Gilmore. 153*86d7f5d3SJohn Marino added syslog per Keith Bostic. security features including not 154*86d7f5d3SJohn Marino being willing to run a command owned or writable by other than 155*86d7f5d3SJohn Marino the owner of the crontab 9not working well yet) 156