Roland Hilkenbach
trying to create a user-crontab, I found that crontab -e creates temporary files in /tmp. These files take the name /tmp/crontab.xxx where the extension seems to be the PID of the crontab -e command and thus are easy to guess by other people. Since /tmp is writable by everyone, someone else could possibly create a file following this naming convention, thereby disturbing the crontab command.
I did crontab -e (with cron-3.0.1-84 on SuSE 6.2) as normal user serveral times under different conditions and strace'd what the command did. This are the results (well, only the interesting parts): 1. /tmp/crontab.<pid> does'nt exist ----------------------------------- open("/tmp/crontab.21464", O_RDWR|O_CREAT|O_EXCL, 0600) = 6 getgid() = 114 getuid() = 2814 fchown(6, 2814, 114) = 0 This seems to be ok. The O_CREAT together with O_EXCL ensures that the operation fails if the file already exists. Maybe it would better to temporarily switch back to the callers uid/gid instead of creating the file with root ownership and then changing it's owner and group. But I can't see a security risk in this. 2. /tmp/crontab.<pid> already exists ------------------------------------ open("/tmp/crontab.21533", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists) write(2, "/tmp/crontab.21533: File exists\n", 32) = 32 unlink("/tmp/crontab.21533") = 0 _exit(1) = ? In this case open fails, the existing file is not overwritten, crontab prints an error message and exists. But before exiting the existing file is unlinked, even if the calling user has no permission to do so. I would call this a bug, but unless someone uses temporary files with names like /tmp/crontab.xxx (which probably noone will do except with the crontab command) there is no "real" security problem resulting from this. If the existing file is a symbolic link, only the link is removed - the file it points to it not affected. So there is a possible (theoretical) security problem and probably it would be a good idea to fix it. But regarding the unrealistic conditions under which it appears, I currently don't see a reason to take immediate action in this case. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/