Jim Meyering <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
