GNU bug report logs - #15232
cp: "-i a/s b/s c" ask for confirmation then still fails

Previous Next

Full log

Message #17 received at 15232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Bob Proulx <bob <at> proulx.com>
Cc: 15232 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Thu, 19 Sep 2013 07:55:20 -0700

On Wed, Sep 18, 2013 at 11:19 AM, Bob Proulx <bob <at> proulx.com> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.