bug#11100: Racy code in copy.c

2021-11-18 Thread Jim Meyering
On Thu, Nov 18, 2021 at 8:38 AM Paul Eggert wrote: > I spotted a SELinux security-context race introduced by the circa-2012 > fix for Bug#11100, and installed the attached patch into coreutils > master. This also gets rid of a label and goto (which is what led me to > find the issue). Nice!

bug#11100: Racy code in copy.c

2021-11-18 Thread Paul Eggert
I spotted a SELinux security-context race introduced by the circa-2012 fix for Bug#11100, and installed the attached patch into coreutils master. This also gets rid of a label and goto (which is what led me to find the issue).From d0f035fc64fb348cb092fbb6ae7e8ce76b4d82db Mon Sep 17 00:00:00

bug#11100: Racy code in copy.c

2012-05-07 Thread Philipp Thomas
* Jim Meyering (j...@meyering.net) [20120504 17:30]: If there's a bugzilla reference for this, let me know and I'll add it to the commit log. There is, but as it's a SLES bug it's only open for SUSE employees and customers and thus useless for a coreutils commit log. I'll instead reference the

bug#11100: Racy code in copy.c

2012-05-07 Thread Jim Meyering
Philipp Thomas wrote: * Jim Meyering (j...@meyering.net) [20120504 17:30]: If there's a bugzilla reference for this, let me know and I'll add it to the commit log. There is, but as it's a SLES bug it's only open for SUSE employees and customers and thus useless for a coreutils commit log.

bug#11100: Racy code in copy.c

2012-05-06 Thread Jim Meyering
Jim Meyering wrote: Philipp Thomas wrote: * Jim Meyering (j...@meyering.net) [20120328 18:09]: At first glance, that might be reasonable: the additional open is incurred only after a failed stat. I'll look more closely in a week or two if no one else investigates. Ping, it's been more than

bug#11100: Racy code in copy.c

2012-05-06 Thread Jim Meyering
Pádraig Brady wrote: I can't think of any issue with this. Code looks good. Test triggers the new condition. Thanks for the review. I've squashed the test-adding commit onto the fix, added this sentence to NEWS: With NFS attribute caching, the condition was particularly easy to

bug#11100: Racy code in copy.c

2012-05-04 Thread Philipp Thomas
* Jim Meyering (j...@meyering.net) [20120328 18:09]: At first glance, that might be reasonable: the additional open is incurred only after a failed stat. I'll look more closely in a week or two if no one else investigates. Ping, it's been more than two weeks and I'm being bugged for a

bug#11100: Racy code in copy.c

2012-05-04 Thread Jim Meyering
Philipp Thomas wrote: * Jim Meyering (j...@meyering.net) [20120328 18:09]: At first glance, that might be reasonable: the additional open is incurred only after a failed stat. I'll look more closely in a week or two if no one else investigates. Ping, it's been more than two weeks and I'm

bug#11100: Racy code in copy.c

2012-05-04 Thread Eric Blake
On 05/04/2012 08:47 AM, Jim Meyering wrote: * src/copy.c (copy_reg): In a narrow race (stat sees dest, yet open-without-O_CREAT fails with ENOENT), retry the open with O_CREAT. Reported by Philipp Thomas and Neil F. Brown in http://debbugs.gnu.org/11100 Question - when we retry with adding

bug#11100: Racy code in copy.c

2012-05-04 Thread Jim Meyering
Eric Blake wrote: On 05/04/2012 08:47 AM, Jim Meyering wrote: * src/copy.c (copy_reg): In a narrow race (stat sees dest, yet open-without-O_CREAT fails with ENOENT), retry the open with O_CREAT. Reported by Philipp Thomas and Neil F. Brown in http://debbugs.gnu.org/11100 Question - when

bug#11100: Racy code in copy.c

2012-05-04 Thread Jim Meyering
Eric Blake wrote: On 05/04/2012 08:47 AM, Jim Meyering wrote: * src/copy.c (copy_reg): In a narrow race (stat sees dest, yet open-without-O_CREAT fails with ENOENT), retry the open with O_CREAT. Reported by Philipp Thomas and Neil F. Brown in http://debbugs.gnu.org/11100 Question - when we

bug#11100: Racy code in copy.c

2012-03-28 Thread Jim Meyering
NeilBrown wrote: On Tue, 27 Mar 2012 15:40:25 +0200 Jim Meyering j...@meyering.net wrote: Philipp Thomas wrote: I'd like to pass on observations from my collegue Neil Brown: in src/copy.c, copy_reg() is passed bool *new_dst. This is 'false' if the file already exists, in which case it

bug#11100: Racy code in copy.c

2012-03-28 Thread NeilBrown
On Wed, 28 Mar 2012 18:07:51 +0200 Jim Meyering j...@meyering.net wrote: NeilBrown wrote: On Tue, 27 Mar 2012 15:40:25 +0200 Jim Meyering j...@meyering.net wrote: Philipp Thomas wrote: I'd like to pass on observations from my collegue Neil Brown: in src/copy.c, copy_reg() is

bug#11100: Racy code in copy.c

2012-03-28 Thread Paul Eggert
On 03/28/2012 09:07 AM, Jim Meyering wrote: if ((use_stat - ? stat (dst_name, dst_sb) + ? (stat (dst_name, dst_sb) 0 ? -1 : +(fd = open (dst_name, O_WRONLY)) 0 ? -1 : 0) : lstat (dst_name, dst_sb)) != 0) At first glance, that

bug#11100: Racy code in copy.c

2012-03-27 Thread Philipp Thomas
I'd like to pass on observations from my collegue Neil Brown: in src/copy.c, copy_reg() is passed bool *new_dst. This is 'false' if the file already exists, in which case it attempts to open the file with O_WRONLY | O_TRUNC | O_BINARY. If it is 'true', only then does it use O_CREAT (and others).

bug#11100: Racy code in copy.c

2012-03-27 Thread Jim Meyering
Philipp Thomas wrote: I'd like to pass on observations from my collegue Neil Brown: in src/copy.c, copy_reg() is passed bool *new_dst. This is 'false' if the file already exists, in which case it attempts to open the file with O_WRONLY | O_TRUNC | O_BINARY. If it is 'true', only then does

bug#11100: Racy code in copy.c

2012-03-27 Thread Philipp Thomas
Hi Jim, * Jim Meyering (j...@meyering.net) [20120327 15:40]: If you can find a way to make cp work sensibly in your specific case, yet without impacting any other use case, please let us know. Thanks for the clarification! In that light though I doubt there is a way :( Philipp

bug#11100: Racy code in copy.c

2012-03-27 Thread Pádraig Brady
On 03/27/2012 01:58 PM, Philipp Thomas wrote: I'd like to pass on observations from my collegue Neil Brown: in src/copy.c, copy_reg() is passed bool *new_dst. This is 'false' if the file already exists, in which case it attempts to open the file with O_WRONLY | O_TRUNC | O_BINARY. If it

bug#11100: Racy code in copy.c

2012-03-27 Thread Paul Eggert
On 03/27/2012 05:58 AM, Philipp Thomas wrote: The above mentioned code assumes that the file still exists. This is racy - particularly for NFS where deletions from other clients can take a while to appear. *NEW_DST is a bit more complicated than that. At least for part of the code it means

bug#11100: Racy code in copy.c

2012-03-27 Thread NeilBrown
On Tue, 27 Mar 2012 15:40:25 +0200 Jim Meyering j...@meyering.net wrote: Philipp Thomas wrote: I'd like to pass on observations from my collegue Neil Brown: in src/copy.c, copy_reg() is passed bool *new_dst. This is 'false' if the file already exists, in which case it attempts to