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

Previous Next

Package: coreutils;

Reported by: jidanni <at> jidanni.org

Date: Sun, 1 Sep 2013 07:40:01 UTC

Severity: wishlist

Tags: confirmed

To reply to this bug, email your comments to 15232 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Sun, 01 Sep 2013 07:40:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to jidanni <at> jidanni.org:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Sun, 01 Sep 2013 07:40:02 GMT) Full text and rfc822 format available.

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

From: jidanni <at> jidanni.org
To: bug-coreutils <at> gnu.org
Subject: cp -i a/s b/s c
Date: Sun, 01 Sep 2013 15:37:51 +0800
$ cp -i a/s b/s c
cp: overwrite ‘c/s’? y
cp: will not overwrite just-created ‘c/s’ with ‘b/s’
Mmmm OK, but maybe don't ask then.




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Sun, 01 Sep 2013 17:35:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: jidanni <at> jidanni.org
Cc: 15232 <at> debbugs.gnu.org
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Sun, 01 Sep 2013 18:34:01 +0100
On 09/01/2013 08:37 AM, jidanni <at> jidanni.org wrote:
> $ cp -i a/s b/s c
> cp: overwrite ‘c/s’? y
> cp: will not overwrite just-created ‘c/s’ with ‘b/s’
> Mmmm OK, but maybe don't ask then.

This is a fair point.
There are two ways to handle this.
1. Do allow the overwrite if 'y' answered.
2. Don't prompt and just display the error.

Case 1 could be useful if you wanted to give
priority to the last item copied in.
However there would be an ambiguity in that case,
as you wouldn't know if the prompt was for an
existing file or a newly copied file.
Also that use case is handled with -n anyway,
by just ordering the parameters according to priority.
So option 2 as you suggest seems like the right thing to do.

So this is a generally means we might only prompt
_after_ we discount all cases that aren't allowed.
Another for example is:

$ rm -f c/s && mkdir c/s && cp -i a/s b/s c
cp: overwrite `c/s'? y
cp: cannot overwrite directory `c/s' with non-directory
cp: overwrite `c/s'? y
cp: cannot overwrite directory `c/s' with non-directory

But then on the other hand, if you did answer 'n' above,
the exit code from cp would be 'success' rather than 'failure'.
I.E. it would be a change in behavior to adjust this,
rather than just a prompt avoidance.
I.E. it's only a redundant prompt when you answer 'y'.

So I'm inclined to leave this as is?

thanks,
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Mon, 02 Sep 2013 00:10:02 GMT) Full text and rfc822 format available.

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

From: jidanni <at> jidanni.org
To: p <at> draigbrady.com
Cc: 15232 <at> debbugs.gnu.org
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Mon, 02 Sep 2013 08:08:55 +0800
All I know is that if it is smart enough to say
>> cp: will not overwrite just-created ‘c/s’ with ‘b/s’
which is indeed rather smart, then it should be smart enough to
gather all its thoughts together before presenting them to the user.
Hmmm, then it should be also smart enough to recognize the collision and
stop before any of it happens...

By which time the algorithm to prevent user error becomes so big as to
introduce different errors... so maybe
PB> So I'm inclined to leave this as is?
is the right thing. The only problem is five years later certain "j"
users will rediscover it and write back again expecting a free t-shirt
etc. :-)




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Wed, 18 Sep 2013 18:20:02 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: jidanni <at> jidanni.org
Cc: 15232 <at> debbugs.gnu.org
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Wed, 18 Sep 2013 12:19:33 -0600
> >> 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.

Problems like those are one of the reasons I would use a for loop to
avoid the too smart cp code.

  for f in one two three; do cp $f targetdir/; done

But then I would never use cp -i either.

jidanni <at> jidanni.org wrote:
> All I know is that if it is smart enough to say
> >> cp: will not overwrite just-created ‘c/s’ with ‘b/s’
> which is indeed rather smart, then it should be smart enough to
> gather all its thoughts together before presenting them to the user.
> Hmmm, then it should be also smart enough to recognize the collision and
> stop before any of it happens...

Creeping featurism and bloat.  It should be removed and simplified
rather than embraced and expanded.

> By which time the algorithm to prevent user error becomes so big as to
> introduce different errors... so maybe
> PB> So I'm inclined to leave this as is?
> is the right thing. The only problem is five years later certain "j"
> users will rediscover it and write back again expecting a free t-shirt
> etc. :-)

Have you ever gotten a free t-shirt? :-)

Bob




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Thu, 19 Sep 2013 14:56:02 GMT) Full text and rfc822 format available.

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.




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Thu, 19 Sep 2013 21:03:02 GMT) Full text and rfc822 format available.

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

From: jidanni <at> jidanni.org
To: jim <at> meyering.net
Cc: 15232 <at> debbugs.gnu.org, bob <at> proulx.com
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Fri, 20 Sep 2013 05:02:25 +0800
>>>>> "JM" == Jim Meyering <jim <at> meyering.net> writes:

JM> enough that without it, cp is vulnerable to a subtle type of exploit.

Well some word about this should be in some footnote in the cp INFO manual.




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Fri, 20 Sep 2013 06:23:01 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: jidanni <at> jidanni.org
Cc: 15232 <at> debbugs.gnu.org, jim <at> meyering.net, bob <at> proulx.com
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Fri, 20 Sep 2013 08:21:48 +0200
On 09/19/2013 11:02 PM, jidanni <at> jidanni.org wrote:
>> Jim Meyering <jim <at> meyering.net> writes:
> 
>> enough that without it, cp is vulnerable to a subtle type of exploit.
> 
> Well some word about this should be in some footnote in the cp INFO manual.

It would be vulnerable "without it", as Jim wrote.
So I don't think the man or info pages are the right place.
We even have a test case for that:
http://git.sv.gnu.org/cgit/coreutils.git/tree/tests/cp/abuse.sh

BTW: I'm not sure if we're talking about two different things now:
The OP was talking about ordinary files a/s and b/s which leads to

  cp: will not overwrite just-created 'c/s' with 'b/s'

whereas Jim is talking about a/s being a symlink which leads to

  cp: will not copy 'b/s' through just-created symlink 'c/s'

Have a nice day,
Berny




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Fri, 20 Sep 2013 08:39:02 GMT) Full text and rfc822 format available.

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

From: jidanni <at> jidanni.org
To: mail <at> bernhard-voelker.de
Cc: 15232 <at> debbugs.gnu.org, jim <at> meyering.net, bob <at> proulx.com
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Fri, 20 Sep 2013 16:38:19 +0800
>>>>> "BV" == Bernhard Voelker <mail <at> bernhard-voelker.de> writes:
BV> So I don't think the man or info pages are the right place.
Huh? Hush hush for security, or just not to bog the pages down?
BV> BTW: I'm not sure if we're talking about two different things now:
(All one big blur to me anyway.)




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Fri, 20 Sep 2013 09:20:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: jidanni <at> jidanni.org
Cc: 15232 <at> debbugs.gnu.org, jim <at> meyering.net, bob <at> proulx.com
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Fri, 20 Sep 2013 11:19:40 +0200 (CEST)
> On September 20, 2013 at 10:38 AM jidanni <at> jidanni.org wrote:
>> "BV" == Bernhard Voelker <mail <at> bernhard-voelker.de> writes:
>> So I don't think the man or info pages are the right place.
>
> Huh? Hush hush for security, or just not to bog the pages down?

No, there is no (known) security problem.  Please read Jim's message
again: there *would be* a security issue if the additional check was
removed.

Have a nice day,
Berny




Information forwarded to bug-coreutils <at> gnu.org:
bug#15232; Package coreutils. (Fri, 20 Sep 2013 09:29:02 GMT) Full text and rfc822 format available.

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

From: jidanni <at> jidanni.org
To: mail <at> bernhard-voelker.de
Cc: 15232 <at> debbugs.gnu.org, jim <at> meyering.net, bob <at> proulx.com
Subject: Re: bug#15232: cp -i a/s b/s c
Date: Fri, 20 Sep 2013 17:28:15 +0800
>>>>> "BV" == Bernhard Voelker <mail <at> bernhard-voelker.de> writes:
BV> No, there is no (known) security problem.  Please read Jim's message

OK then the ought to add a footnote to the docs.




Severity set to 'wishlist' from 'normal' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 21 Oct 2018 20:43:01 GMT) Full text and rfc822 format available.

Added tag(s) confirmed. Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 21 Oct 2018 20:43:02 GMT) Full text and rfc822 format available.

Changed bug title to 'cp: "-i a/s b/s c" ask for confirmation then still fails' from 'cp -i a/s b/s c' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 21 Oct 2018 20:43:02 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 299 days ago.

Previous Next


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