Mailinglist Archive: opensuse-security (192 mails)

< Previous Next >
Re: [suse-security] temporary files created by crontab -e
  • From: Eilert Brinkmann <eilert@xxxxxxxxxxxxxxxxxxxxxxxx>
  • Date: 05 May 2000 14:09:53 +0200
  • Message-id: <xttog6lxkoe.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Roland Hilkenbach <roland@xxxxxxxxxxxxxxxxxx> wrote:
> trying to create a user-crontab, I found that crontab -e creates
> temporary files in /tmp. These files take the name /tmp/
> 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/ (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 Brinkmann -- Universitaet Bremen -- FB 3, Informatik
eilert@xxxxxxxxxxxxxxxxxxxxxxxx - eilert@xxxxxxx - eilert@xxxxxxxxxxxxxx

< Previous Next >