Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 69796 - Permission denied trying to install crontab from a file
Summary: Permission denied trying to install crontab from a file
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Cron Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-01 22:00 UTC by Marko Vallius
Modified: 2004-11-04 08:20 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marko Vallius 2004-11-01 22:00:49 UTC
After upgrading from vixie-cron-3.0.1-r4 to vixie-cron-4.1-r2, 'crontab file' stops working:

$ crontab foobar
crontabs/tmp.XXXXT1VBKj: Permission denied

Commands crontab -e, crontab -l and crontab -r work and cron jobs are still run. 

Reproducible: Always
Steps to Reproduce:




Output from 'emerge info': 
 
Gentoo Base System version 1.4.16 
Portage 2.0.51-r2 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r1, 
2.6.8-gentoo-r3 i686) 
================================================================= 
System uname: 2.6.8-gentoo-r3 i686 AMD Athlon(tm) XP 2600+ 
distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) 
[enabled] 
Autoconf: sys-devel/autoconf-2.59-r5 
Automake: sys-devel/automake-1.8.5-r1 
Binutils: sys-devel/binutils-2.14.90.0.8-r1 
Headers:  
sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1 
Libtools: sys-devel/libtool-1.5.2-r5 
ACCEPT_KEYWORDS="x86" 
AUTOCLEAN="yes" 
CFLAGS="-march=i686 -O2 " 
CHOST="i686-pc-linux-gnu" 
COMPILER="" 
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-march=i686 -O2 " 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoaddcvs ccache distcc distlocks sandbox" 
GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ 
http://ftp.cvut.cz/vmware/" 
MAKEOPTS="-j4" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="" 
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" 
USE="3dfx 3dnow 3dnowext X aalib alsa apm arts avi berkdb bitmap-fonts cdr 
crypt cups dvd dvdr encode esd f77 flac foomaticdb gdbm gif gnome gphoto2 gpm 
gtk imlib java jpeg kde libg++ libwww mad mbox mikmod mmx mmx2 monkey motif 
mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pda pdflib perl png 
ppds python qt quicktime readline sasl scanner sdl slang spell sse sse2 ssl 
svga tcltk tcpd tetex tiff truetype usb x86 xml2 xmms xv zlib 
video_cards_matrox"
Comment 1 Tuan Van (RETIRED) gentoo-dev 2004-11-01 23:12:05 UTC
man crontab
pay attention to /etc/cron.allow and /etc/cron.deny
Comment 2 Marko Vallius 2004-11-01 23:27:41 UTC
Been there, done that:

- /etc/cron.allow does not exist
- /etc/cron.deny is empty 
- user is (still) in cron group

I'd imagine other crontab options should be affected, if any of the above were not correct. Also, after downgrading to vixie-cron-3.0 everything works as it should.
Comment 3 Tuan Van (RETIRED) gentoo-dev 2004-11-02 09:46:11 UTC
looks like perms issue with `/var/spool/cron/crontabs'
Comment 4 Marko Vallius 2004-11-02 10:22:01 UTC
Permissions seem quite correct (assuming they should be the same as in vixie-cron-3.0.1):

drwxr-x---  4 root cron 120 Oct  4 13:20 /var/spool/cron/
drwxr-x---  2 root cron  96 Nov  2 10:14 /var/spool/cron/crontabs/

crontab binary looks also good:

-rwsr-x---  1 root cron 29600 Nov  1 23:18 /usr/bin/crontab*

The crontab gets installed if I run 'crontab -e'. It's just this one special case that does not work. Does 'crontab file' try to create a temporary file in /dev/null or what?
Comment 5 Marko Vallius 2004-11-02 11:49:53 UTC
Narrowing it down: reading the new crontab from stdin works.

Now if I read the source correctly, the only functional difference between 'crontab - < file' and 'crontab file' is that crontab calls swap_uids() to relinquish its setuid status before opening the user's own crontab file (which is not needed when reading stdin). After the file has been read, it goes back to root by calling swap_uids_back(). 3.0.1 just calls swap_uids() again. Maybe something goes wrong here but it is not noticed?
Comment 6 Aaron Walker (RETIRED) gentoo-dev 2004-11-04 02:57:44 UTC
Marko, good job narrowing it down.  Certainly saved me a little time.

swap_uids_back() contains:

   return ((setegid(getgid()) || seteuid(getuid())) ? -1 : 0);

which makes absolutely no sense, since it should be swapping back to the saved uid/gid (save_euid and save_egid, respectively).

I've uploaded a new patch revision to be distributed to the mirrors, so in 5-6 hours I'll do a version bump and close this bug.

Thanks for the report.
Comment 7 Aaron Walker (RETIRED) gentoo-dev 2004-11-04 08:20:32 UTC
4.1-r3 is in CVS.  Thanks again for the report.