1*0061c6a5SchristosISC Cron V4 2*0061c6a5Schristos 3*0061c6a5Schristos9. [misc] megapatch from tcmiller (posix compliance, etc). 4*0061c6a5Schristos8. [bug] fix stepsize 0 infinite loop. 5*0061c6a5Schristos7. [evol] "enum" version of freebsd fix to env-var settings. 6*0061c6a5Schristos6. [evol] changes #12-17 from tcmiller (for *BSD alignment). 7*0061c6a5Schristos5. [feature] give cron a version number and display it. 8*0061c6a5Schristos4. [bug] handle clock jumps (from freebsd pr# 24485) 9*0061c6a5Schristos3. [feature] add -n to cron (for nofork). 10*0061c6a5Schristos2. [evol] merge in many changes from *BSD and Linux. 11*0061c6a5Schristos1. [port] fixups for nextstep, plus a syslog configuration bug. 12*0061c6a5Schristos 13*0061c6a5Schristos-------- 14*0061c6a5Schristos 15*0061c6a5SchristosVixie Cron V3.0 Patch 2 notes 16*0061c6a5SchristosPaul Vixie 17*0061c6a5Schristos12-Dec-1994 18*0061c6a5Schristos 19*0061c6a5Schristos3. "Coherent" now supported. All kinds of flock() damage was repaired. 20*0061c6a5Schristos2. gethostname() now available in compat.c for systems that need it. 21*0061c6a5Schristos1. There was a problem in the way the environment was being imported. 22*0061c6a5Schristos 23*0061c6a5SchristosVixie Cron Changes from V2 to V3 24*0061c6a5SchristosPaul Vixie 25*0061c6a5Schristos29-Dec-1993 26*0061c6a5Schristos 27*0061c6a5SchristosThe crontab command now conforms to POSIX 1003.2. This means that when you 28*0061c6a5Schristosinstall it, if you have any "crontab" command lines floating around in shell 29*0061c6a5Schristosscripts (such as /etc/rc or /etc/rc.local), you will need to change them. 30*0061c6a5Schristos 31*0061c6a5SchristosI have integrated several changes made by BSDi for their BSD/386 operating 32*0061c6a5Schristossystem; these were offerred to me before I started consulting for them, so 33*0061c6a5Schristosit is safe to say that they were intended for publication. Most notably, 34*0061c6a5Schristosthe name of the cron daemon has changed from "crond" to "cron". This was 35*0061c6a5Schristosdone for compatibility with 4.3BSD. Another change made for the same reason 36*0061c6a5Schristosis the ability to read in an /etc/crontab file which has an extra field in 37*0061c6a5Schristoseach entry, between the time fields and the command. This field is a user 38*0061c6a5Schristosname, and it permits the /etc/crontab command to contain commands which are 39*0061c6a5Schristosto be run by any user on the system. /etc/crontab is not "installed" via 40*0061c6a5Schristosthe crontab(1) command; it is automatically read at startup time and it will 41*0061c6a5Schristosbe reread whenever it changes. 42*0061c6a5Schristos 43*0061c6a5SchristosI also added a "-e" option to crontab(1). Nine people also sent me diffs 44*0061c6a5Schristosto add this option, but I had already implemented it on my own. I actually 45*0061c6a5Schristosreleased an interrim version (V2.2, I think) for limited testing, and got a 46*0061c6a5Schristoschance to fix a bad security bug in the "-e" option thanks to XXX. 47*0061c6a5Schristos 48*0061c6a5SchristosThe daemon used to be extraordinarily sloppy in its use of file descriptors. 49*0061c6a5SchristosA heck of a lot of them were left open in spawned jobs, which caused problems 50*0061c6a5Schristosfor the daemon and also caused problems with the spawned jobs if they were 51*0061c6a5Schristosshell scripts since "sh" and "csh" have traditionally used hidden file 52*0061c6a5Schristosdescriptors to pass information to subshells, and cron was causing them to 53*0061c6a5Schristosthink they were subshells. If you had trouble with "sh" or "csh" scripts in 54*0061c6a5SchristosV2, chances are good that V3 will fix your problems. 55*0061c6a5Schristos 56*0061c6a5SchristosAbout a dozen people have reminded me that I forgot to initialize 57*0061c6a5Schristos"crontab_fd" in database.c. Keith Cantrell was the first, so he gets the 58*0061c6a5Schristospoint. 59*0061c6a5Schristos 60*0061c6a5SchristosSteve Simmons reminded me that once an account has been deleted from the 61*0061c6a5Schristossystem, "crontab -u USER -d" will not work. My solution is to suggest to 62*0061c6a5Schristosall of you that before you delete a user's account, you first delete that 63*0061c6a5Schristosuser's crontab file if any. From cron's point of view, usernames can never 64*0061c6a5Schristosbe treated as arbitrary strings. Either they are valid user names, or they 65*0061c6a5Schristosare not. I will not make an exception for the "-d" case, for security 66*0061c6a5Schristosreasons that I consider reasonable. It is trivial for a root user to delete 67*0061c6a5Schristosthe entry by hand if necessary. 68*0061c6a5Schristos 69*0061c6a5SchristosDan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of 70*0061c6a5Schristosothers also reminded me of this, but Dan gets the point. I didn't fix it 71*0061c6a5Schristosthere, since the real bug was that it should have been open in the parent. 72*0061c6a5Schristos 73*0061c6a5SchristosPeter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in 74*0061c6a5Schristosmisc.c. Hans Trompert actually told me first, but Peter sent the patch so 75*0061c6a5Schristoshe gets the point. 76*0061c6a5Schristos 77*0061c6a5SchristosRussell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c, 78*0061c6a5Schristoswhich explains why a lot of other people complained that it wasn't using 79*0061c6a5Schristossyslog even when they configured it that way :-). Steve Simmons told me 80*0061c6a5Schristosfirst, though, so he gets the point. 81*0061c6a5Schristos 82*0061c6a5SchristosAn interrim version of the daemon tried to "stat" every file before 83*0061c6a5Schristosexecuting it; this turned out to be a horribly bad idea since finding the 84*0061c6a5Schristosname of a file from a shell command is a hard job (that's why we have 85*0061c6a5Schristosshells, right?) I removed this bogus code. Dave Burgess gets the point. 86*0061c6a5Schristos 87*0061c6a5SchristosDennis R. Conley sent a suggestion for MMDF systems, which I've added to the 88*0061c6a5Schristoscomments in cron.h. 89*0061c6a5Schristos 90*0061c6a5SchristosMike Heisler noted that I use comments in the CONVERSION file which are 91*0061c6a5Schristosdocumented as illegal in the man pages. Thanks, Mike. 92*0061c6a5Schristos 93*0061c6a5SchristosIrving Wolfe sent me some very cheerful changes for a NeXT system, but I 94*0061c6a5Schristosconsider the system itself broken and I can't bring myself to #ifdef for 95*0061c6a5Schristossomething as screwed up as this system seems to be. However, various others 96*0061c6a5Schristosdid send me smaller patches which appear to have cause cron to build and run 97*0061c6a5Schristoscorrectly on (the latest) NeXT machines, with or without the "-posix" CFLAG. 98*0061c6a5SchristosIrving also asked for a per-job MAILTO, and this was finally added later when 99*0061c6a5SchristosI integrated the BSD/386 changes contributed by BSDi, and generalized some of 100*0061c6a5Schristosthe parsing. 101*0061c6a5Schristos 102*0061c6a5SchristosLots of folks complained that the autogenerated "Date:" header wasn't in 103*0061c6a5SchristosARPA format. I didn't understand this -- either folks will use Sendmail and 104*0061c6a5Schristosnot generate a Date: at all (since Sendmail will do it), or folks will use 105*0061c6a5Schristossomething other than Sendmail which won't care about Date: formats. But 106*0061c6a5SchristosI've "fixed" it anyway... 107*0061c6a5Schristos 108*0061c6a5SchristosSeveral people suggested that "*" should be able to take a "/step". One person 109*0061c6a5Schristossuggested that "N/step" ought to mean "N-last/step", but that's stretching things 110*0061c6a5Schristosa bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb 111*0061c6a5Schristossent in the first and most polite request for this feature. 112*0061c6a5Schristos 113*0061c6a5SchristosAs with every release of Cron, BIND, and seemingly everything else I do, one 114*0061c6a5Schristosuser stands out with the most critical but also the most useful analysis. 115*0061c6a5SchristosCron V3's high score belongs to Peter Holzer, who sent in the nicest looking 116*0061c6a5Schristospatch for the "%" interpretation problem and also helped me understand a 117*0061c6a5Schristostricky bit of badness in the "log_fd" problem. 118*0061c6a5Schristos 119*0061c6a5Schristosagulbra@flode.nvg.unit.no wins the honors for being the first to point out the 120*0061c6a5Schristosnasty security hole in "crontab -r". 'Nuff said. 121*0061c6a5Schristos 122*0061c6a5SchristosSeveral folks pointed out that log_it() needed to exist even if logging was 123*0061c6a5Schristosdisabled. Some day I will create a tool that will compile a subsystem with 124*0061c6a5Schristosevery possible combination and permutation of #ifdef options, but meanwhile 125*0061c6a5Schristosthanks to everybody. 126*0061c6a5Schristos 127*0061c6a5Schristosjob_runqueue() was using storage after freeing it, since Jordan told me back 128*0061c6a5Schristosin 1983 that C let you do that, and I believed him in 1986 when I wrote all 129*0061c6a5Schristosthis junk. Linux was the first to die from this error, and the Linux people 130*0061c6a5Schristossent me the most amazing, um, collection of patches for this problem. Thanks 131*0061c6a5Schristosfor all the fish. 132*0061c6a5Schristos 133*0061c6a5SchristosJeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's 134*0061c6a5Schristosversion of popen/pclose from the ftpd and hacked it to taste. We're safe now, 135*0061c6a5Schristosfrom this at least. 136*0061c6a5Schristos 137*0061c6a5SchristosBranko Lankester sent me a very timely and helpful fix for a looming security 138*0061c6a5Schristosproblem in my "crontab -e" implementation. 139*0061c6a5Schristos 140*0061c6a5Schristos-------- 141*0061c6a5Schristos 142*0061c6a5SchristosVixie Cron Changes from V1 to V2 143*0061c6a5SchristosPaul Vixie 144*0061c6a5Schristos8-Feb-1988 145*0061c6a5Schristos 146*0061c6a5SchristosMany changes were made in a rash of activity about six months ago, the exact 147*0061c6a5Schristoslist of which is no longer clear in my memory. I know that V1 used a file 148*0061c6a5Schristoscalled POKECRON in /usr/spool/cron to tell it that it was time to re-read 149*0061c6a5Schristosall the crontab files; V2 uses the modtime the crontab directory as a flag to 150*0061c6a5Schristoscheck out the crontab files; those whose modtime has changed will be re-read, 151*0061c6a5Schristosand the others left alone. Note that the crontab(1) command will do a utimes 152*0061c6a5Schristoscall to make sure the mtime of the dir changes, since the filename/inode will 153*0061c6a5Schristosoften remain the same after a replacement and the mtime wouldn't change in 154*0061c6a5Schristosthat case. 155*0061c6a5Schristos 156*0061c6a5Schristos8-Feb-88: made it possible to use much larger environment variable strings. 157*0061c6a5Schristos V1 allowed 100 characters; V2 allows 1000. This was needed for PATH 158*0061c6a5Schristos variables on some systems. Thanks to Toerless Eckert for this idea. 159*0061c6a5Schristos E-mail: UUCP: ...pyramid!fauern!faui10!eckert 160*0061c6a5Schristos 161*0061c6a5Schristos16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to 162*0061c6a5Schristos /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny}, 163*0061c6a5Schristos since the sysv naming for this depends on 'at' using the same 164*0061c6a5Schristos dir, which would be stupid (hint: use /usr/{lib,spool}/at). 165*0061c6a5Schristos 166*0061c6a5Schristos22-Feb-88: made it read the spool directory for crontabs and look each one 167*0061c6a5Schristos up using getpwnam() rather than reading all passwds with getpwent() 168*0061c6a5Schristos and trying to open each crontab. 169*0061c6a5Schristos 170*0061c6a5Schristos9-Dec-88: made it sync to :00 after the minute, makes cron predictable. 171*0061c6a5Schristos added logging to /var/cron/log. 172*0061c6a5Schristos 173*0061c6a5Schristos14-Apr-90: (actually, changes since December 1989) 174*0061c6a5Schristos fixed a number of bugs reported from the net and from John Gilmore. 175*0061c6a5Schristos added syslog per Keith Bostic. security features including not 176*0061c6a5Schristos being willing to run a command owned or writable by other than 177*0061c6a5Schristos the owner of the crontab 9not working well yet) 178