Bug 25376 - crontab -e doesn't work
crontab -e doesn't work
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: vixie-cron (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
David Lawrence
Florence RC-1
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-31 09:13 EST by Tim Waugh
Modified: 2007-04-18 12:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-10 18:02:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Waugh 2001-01-31 09:13:23 EST
Try:

crontab -r
unset EDITOR VISUAL
crontab -e

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.
Comment 1 Glen Foster 2001-01-31 16:51:44 EST
This defect is considered MUST-FIX for Florence Release-Candidate #1
Comment 2 Bernhard Rosenkraenzer 2001-02-02 06:41:54 EST
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 
way).
Comment 3 Tim Waugh 2001-02-02 08:19:09 EST
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.
         */
Comment 4 Tim Waugh 2001-02-02 08:21:10 EST
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.
Comment 5 Bernhard Rosenkraenzer 2001-02-02 08:24:19 EST
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).
Comment 6 Bill Nottingham 2001-02-02 12:58:35 EST
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.
Comment 7 Bill Nottingham 2001-02-02 13:22:38 EST
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.

Note You need to log in before you can comment on or make changes to this bug.