xref: /netbsd-src/external/bsd/cron/dist/CHANGES (revision 0061c6a57db8d5f6f7c0f43feb831ed16236a4a2)
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