Red Hat Bugzilla – Bug 25376
crontab -e doesn't work
Last modified: 2007-04-18 12:31:00 EDT
unset EDITOR VISUAL
Modifications are not detected.
This is because vixie-cron compares fstat results from a filedescriptor
before and after editing, but vim-minimal does a 'rename, write new file,
unlink old file' sequence.
Not sure if this is vim's fault or vixie-cron's.
This defect is considered MUST-FIX for Florence Release-Candidate #1
This should probably be fixed in cron, since there are other editors doing the
same things and a user can export EDITOR="just about anything".
I'll try to fix vim though. (vim-enhanced doesn't have this problem, by the
Hmm, here's what a comment in the source says:
/* we still have the file open. editors will generally rewrite the
* original file rather than renaming/unlinking it and starting a
* new one; even backup files are supposed to be made by copying
* rather than by renaming. if some editor does not support this,
* then don't use it. the security problems are more severe if we
* close and reopen the file around the edit.
Thinking about it, this seems sucky. I think crontab is too paranoid here: why
can't it make a secure tmp directory and plonk the file in there?
But maybe there's a security thing I've overlooked.
vim 0.6-0.23 handles this correctly, so it's no longer a vim issue.
I still think it should be fixed in cron though. I don't see a security
problem either (unless we're overlooking the same thing).
There apparently is a security problem; the recent advisory from
Debian & FreeBSD is fixed by making the checks that it's editing
the file in place even *more* stringent.
I'm currently trying to reproduce the problem to see if there
is a different way to fix it.
OK, there are two things here.
The security problem had to do with the case where the
user unlinks the file they are editing, and symlinks it to
something else. We're not currently vulnerable to this, because
we have the same fix more-or-less already integrated.
I'm not sure how to close and reopen the file and *not* be
vulnerable to this, as the crontab file pretty much has to
be somewhere writable by the user.