On Fri, Mar 28, 2008 at 12:44:25PM -0400, Justin Pryzby wrote: > On Thu, Mar 27, 2008 at 11:35:10AM +0000, River Tarnell wrote:
> > JP> a non-issue in cron, right? However it seems that cron perhaps should > > JP> have sent some warning messages/logs if an error was encountered. Is > > JP> this correct? > > > > sorry for taking so long to reply - yes, i think that's correct. > it returns nonzero exit status, so I think it should log that, and > also warn the user by mail (even if the command output nothing else). > > I sent patches to #155109 to implement that. [...] > > if the last time of the crontab lacks a newline, the line will be > > ignored (and jobs won't run). i haven't gotten around to filing a > I think that bug was separately reported, and unfortunately was > resolved simply by adding a note to crontab.[15]. It's reasonable IMO > to consider it a bug. This is bug#76625, which now has 2 patches (one of them mine). The earlier patch allows a file to end without a newline. Although this is the "comfortable" behavior, I like the subtle assertiveness of the intent of the upstream crontab's requirement. A file not ending in a newline might have been truncated (eg. due to ENOSPC) and that may even constitute a vulnerability (fill up the /var partition with one's own crontab such that when some other user tries to write/update theirs, the partial crontab runs command "foo /bar" rather than "foo /bar/baz" or "foo /home/john" rather than "foo /home/johnk" or ...). The behavior of my own patch isn't ideal, in particular since the "edit" path doesn't benefit from this parsing check. If it's okay with you, I'll close this (#443615) bug rept, since the remaining (2ndary) issues are addressed in other bugs. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
