Bug 141760 - cannot edit existing crontabs
cannot edit existing crontabs
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
: 142176 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-12-03 11:44 EST by Matthew Galgoci
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-20 02:51:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Galgoci 2004-12-03 11:44:29 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

How reproducible:


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.
Actual results:

previous crontab is overwritten

Expected results:

I'd expect to be able to edit an existing crontab entry
Comment 1 Matthew Galgoci 2004-12-03 11:49:24 EST
Further, this happens regardless of selinux being enabled or not.
Comment 2 Jason Vas Dias 2004-12-03 12:01:18 EST
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)
and emacs.
Comment 3 Matthew Galgoci 2004-12-03 12:15:57 EST
You didn't try on ppc did you?

You can ssh to chimay.ges.redhat.com as yourself and reproduce the
bug easily.
Comment 4 Jason Vas Dias 2004-12-03 12:24:19 EST
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
Comment 5 Matthew Galgoci 2004-12-03 12:28:53 EST
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.
Comment 6 Matthew Galgoci 2004-12-03 12:33:04 EST
That error is coming from your shell on your local machine. I think
you b0rked your local setup. :)
Comment 7 Matthew Galgoci 2004-12-03 12:39:00 EST
To make matters even more fun, it works fine if I strace it as root.

strace -o foo -f crontab -e


crontab -e

Comment 8 Jason Vas Dias 2004-12-03 12:50:48 EST
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 jvdias@redhat.com? Thanks.

Comment 9 Jason Vas Dias 2004-12-03 13:18:18 EST
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
/var/spool/cron directory. 
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.

Comment 10 Jason Vas Dias 2004-12-03 17:06:31 EST
 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 .
Comment 11 Jason Vas Dias 2004-12-08 14:21:31 EST
*** Bug 142176 has been marked as a duplicate of this bug. ***
Comment 13 Marius Andreiana 2005-08-20 02:51:40 EDT
Setting platform to powerpc
Marking fixed in rawhide per comment #10 and no feedback. If still not working,
please reopen.

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