Re: Race-condition ?

[Gaëtan LEURENT]

Eli Zaretskii wrote on 24 Jun 2005 22:07:35 +0200:

> So?  What problems would that cause, except defeating the call to
> chown itself?  Previous versions of Emacs didn't call chown at all, so
> how is the current version worse?
>
> It's possible that this race condition is harmful in the context of
> bzip2, but that doesn't necessarily mean it's as harmful in Emacs.
>
>> I believe we should use fchown instead.
>
> Only if the danger is real, IMHO: fchown requires that we open the
> file, which is expensive.  If we go that way, we might as well check
> if we are root, and only open the file and call fchown if we are: no
> need to punish mere mortals if we know in advance the call will fail
> for them anyway.

I guess I haven't been clear enough. The scenario is:

- Suppose the users have two directory in two different drives. For
  instance in /home which is a small drive with frequent backups, and in
  /large which is a large drive without backups.

- Now, root is using emacs. He decides to move the file
  /home/joe/somefile to /large/joe/somefile because it takes too much
  place on the small drive.

- Since /home and /large are on different filesystems, emacs will copy
  the content of /home/joe/somefile to /large/joe/somefile and will then
  call chown on /large/joe/somefile.

- But joe is a bad guy, and while emacs is copying the file, he removes
  /large/joe/somefile and replaces it with a hardlink to
  /large/root/importantfile (possibly /etc/passwd if it's on the same
  drive).

- When emacs finishes to copy the file, it call chown on
  /large/joe/somefile, and joe now owns /large/root/importantfile.

The problem is that chown takes a path as argument, and paths are not
safe in a Unix environment. What we must do is use fchown which takes a
filedescriptor as argument, and give it the fd we got *when we opened
the new file in the first place*. We must not close the file before we
call fchown, and we must not open it second time. This induce no
additional cost and it is the only way to be sure we are dealing with
the same file.

You can build the same kind of attack with chmod.

The attack is not very likely because it requires that the target
directory is writable by the victim and by the attacker, which can
happen it root is playing with someone else's file or if the victim is
doing things in a world writable directory, but it the same as the one
that was found in bzip2.

> Anyway, how portable are fchown and fchmod?  If not all platforms
> support them, we shouldn't introduce them without an Autoconf test.

According to Linux's man files:
# The fchmod call conforms to 4.4BSD and SVr4.  SVr4 documents additional
# EINTR and ENOLINK error conditions.  POSIX requires the fchmod function
# if at least one of _POSIX_MAPPED_FILES and _POSIX_SHARED_MEMORY_OBJECTS
# is  defined,  and  documents  additional ENOSYS and EINVAL error condi-
# tions, but does not document EIO.

If a platform does not support them, I think we should not try to change
access permissions and/or file owner at all on these platforms.

-- 
Gaëtan LEURENT