GNU bug report logs -
#15232
cp: "-i a/s b/s c" ask for confirmation then still fails
Previous Next
To reply to this bug, email your comments to 15232 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
$ 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):
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):
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):
> >> 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):
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):
>>>>> "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):
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):
>>>>> "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):
> 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):
>>>>> "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.