Red Hat Bugzilla – Bug 141760
cannot edit existing crontabs
Last modified: 2007-11-30 17:10:56 EST
Description of problem:
With vixie-cron-4.1-19 on ppc, I cannot edit existing crontabs.
I can add, remove, list, but not edit.
Editing an existing crontab results in a blank file opened with
$EDITOR and writing the crontab results in any previous entries in
the crontab being overwritten.
Version-Release number of selected component (if applicable):
vixie-cron-4.1-19 on ppc
Steps to Reproduce:
1. create a crontab (crontab -e)
2. add a cronjob or even a comment eg (# bs comment)
3. write the crontab
4. list crontab (crontab -l)
5. edit crontab again (crontab -e)
6. note that your previous entry is missing
7. add another entry or comment
8. write the crontab
9. list the crontab (crontab -l)
10. note that the original crontab entry has been overwritten.
previous crontab is overwritten
I'd expect to be able to edit an existing crontab entry
Further, this happens regardless of selinux being enabled or not.
I can't reproduce this problem with the same vixie-cron-4.1-19 on FC3.
I'm now doing a yum update to the latest rawhide on another machine
to test. What $EDITOR are you using ? I've tried the default (vi)
You didn't try on ppc did you?
You can ssh to chimay.ges.redhat.com as yourself and reproduce the
No, I can't - I get:
$ ssh chimay.ges.redhat.com
You don't exist, go away!
It seems this host has authentication setup problems, which might
explain the crontab problem. I'll be able to test on rawhide-latest
I don't see that jvdias attempted to login at all. Nothing in
/var/log/messages for jvdias or in /var/log/secure.
You do exist because logged in as root I can su to your user and I
have a valid uid/gid matching numerically and by name.
That error is coming from your shell on your local machine. I think
you b0rked your local setup. :)
To make matters even more fun, it works fine if I strace it as root.
strace -o foo -f crontab -e
Yes, sorry - I had temporarily disabled NIS earlier for another test.
I'm now able to login to chimay, and am testing - I see the problem now.
It would be helpful to have a temporary root password - please could
you send one to email@example.com? Thanks.
I think I can see the problem now : the 'setuid' file mode bit
is not being honoured on this system.
/usr/sbin/crontab has mode 4755 ; it is 'setuid' to root.
The /var/spool/cron directory has mode rwx------ - it can ONLY be
read / written / searched by root.
crontab depends on the 'setuid' bit to gain root privilege when
executed by a non root user; it then copies the file to /tmp,
does a 'setuid' to the invoking user, invokes the $EDITOR to edit the
file, setuids back to root, and does a move (rename(2)) of the file
back to /var/spool/cron.
On the chimay system, for some reason crontab is not being 'setuid' to
root when executed.
This is demonstrated by the /tmp/lscron script on chimay, which I made
setuid to root; when run by a non-root user, it gets 'permission
denied', the same as crontab does when it tries to open the
The crontab program and the example setuid 'lscron' script are run
fine by non-root users on FC2 and FC3 - something has changed with
setuid bit functionality in FC4/Rawhide - I'm still investigating
what this might be.
I see the problem now - forget about the setuid issue.
Of course, the setuid bit has no effect when programs are
run under strace / gdb .
I've tested 'crontab -e' on the i386 platform, and it works fine.
Only when vixie-cron is compiled on ppc with the default
-O2 -g -pipe -D_FORTIFY_SOURCE=2 -m32 -fsigned-char
does the problem occur because of a character that was uninitialized
comparing equal to 'EOF' . When compiled without the above
options on ppc crontab also works fine.
While this may be a gcc issue, and does not cause a problem on
other platforms, having the uninitialized character is a bad idea
and I've now submitted vixie-cron-4.1-20 with the change.
This should now be fixed in vixie-cron-4.1-20 .
*** Bug 142176 has been marked as a duplicate of this bug. ***
Setting platform to powerpc
Marking fixed in rawhide per comment #10 and no feedback. If still not working,