bug#15232: cp -i a/s b/s c

[Jim Meyering]

On Wed, Sep 18, 2013 at 11:19 AM, Bob Proulx <address@hidden> wrote:
>> >> cp: will not overwrite just-created ‘c/s’ with ‘b/s’
>
> Personally I have never liked that behavior.  It is trying to be too
> smart.  If I had my "druthers" I would rather see that behavior
> removed.  If I ask for the file to be overwritten twice then I expect
> the file to be overwritten twice.
...
> Creeping featurism and bloat.  It should be removed and simplified
> rather than embraced and expanded.

Hi Bob,
If you don't like the "feature", perhaps I haven't made it clear
enough that without it, cp is vulnerable to a subtle type of exploit.
The trouble arises when there are two files by the same name
(obviously in two separate directories, as in the example), but where
the first one that cp copies is a symlink, and the second one contains
the "payload", which would (without this feature) be copied through
the just-copied symlink.  With that, if some victim (person or script)
can be made to issue such a command, the one who controls the contents
of the source directories can chose the name of a file writable by the
victim as well as the desired contents: cp would do the rest. Sure, it
requires a buggy script, or a cooperative/susceptible victim, but how
many of us would guess that a root-run "cp -p dir.* dest-dir" could be
tricked into doing something bad?

I was sooo glad I spotted that bug before this exploitable cp made it
into a release.

It affected other vendors back then, and probably some even now.