Re: FYI: bug-fix: cp would fail to write through a dangling symlink

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> I'm glad it's only a problem in a very unusual situation
> (copying through a dangling symlink) and on a system that is
> so deficient as to lack fchmod.

On further thought (I'm supposed to be working on something else but
this seems fairly important) it is a problem even on modern systems,
i.e., systems that have fchmod.

The attack is as follows.  'cp' opens the destination without O_EXCL.
'cp' thinks it created the destination (because 'stat' or 'lstat' or
'open'-with-O_EXCL said the destination didn't exist before), but in
the meantime the attacker created a symlink to a victim file.  'cp'
then invokes fchown/fchmod/whatever on the victim file, because it
mistakenly thinks it created the victim.

> Now that you mention this, for starters, I will add O_NOFOLLOW.

This is so that the code can check for ELOOP rather than EEXIST?  Yes,
I suppose that helps a bit.  However, I think we need a more-general
solution against the attack in question.  And once that more-general
solution is in place it shouldn't matter whether O_NOFOLLOW is used,
since O_EXCL will always be used to create a file and O_EXCL is just
as good as O_NOFOLLOW in terms of safety.

> Are you interested?

I'm a bit rushed, but here's a quick cut at a solution.  Perhaps I'll have
time in a few days.

The basic idea is that if 'cp' detects a dangling symlink, it resolves
the link using gnulib's canonicalize_filename_mode (name, CAN_ALL_BUT_LAST).
It then uses O_EXCL on the resolved name.

Obviously there is still a race between detecting the link and opening
the destination file.  But that race is inevitable and cannot be
worked around.  The race I'm worried about is different: it's the one
that fools 'cp' into thinking it created the destination even though
it didn't.