GNU bug report logs - #30534
cp - Possible bugs when not preserving mode (explicit) and when copying special files

Previous Next

Package: coreutils;

Reported by: Declercq Laurent <l.declercq <at> nuxwin.com>

Date: Mon, 19 Feb 2018 17:31:02 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#30534: closed (cp - Possible bugs when not preserving mode
 (explicit) and when copying special files)
Date: Sun, 25 Feb 2018 02:25:01 +0000
[Message part 1 (text/plain, inline)]
Your message dated Sat, 24 Feb 2018 18:24:17 -0800
with message-id <de0e390d-c790-e985-7dac-bae2e7eefa16 <at> draigBrady.com>
and subject line Re: bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files
has caused the debbugs.gnu.org bug report #30534,
regarding cp - Possible bugs when not preserving mode (explicit) and when copying special files
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
30534: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30534
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Declercq Laurent <l.declercq <at> nuxwin.com>
To: bug-coreutils <at> gnu.org
Subject: cp - Possible bugs when not preserving mode (explicit) and when
 copying special files
Date: Mon, 19 Feb 2018 11:22:48 +0100
I think that I did found at least two bugs in cp(1) command when the 
--no-preserve=mode option is involved and when copying special file. I 
describe each of them below.

1. Mode set on special files seem to be wrong:

Original file to copy: prw-rw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile 
spfile_copy

Current result:

prwxr-xr-x 1 root staff 0 févr. 18 22:01 spfile_copy

Expected result (considering UMASK 0022):

prw-r--r-- 1 root staff 0 févr. 18 22:01 spfile_copy

The current behavior is due to the fact that mode used is 0777 while 
0666 should be used for files.

Possible fix: Differentiate directories from files in the copy_internal 
function.

2. Non-permission bits are preserved, even when the --no-preserve=mode 
option is involved.

Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile 
spfile_copy

Current result:

prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy

Expected result (considering UMASK 0022 and without the first bug above):

prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy

Possible solution: Clear-out non-permission bits before calling mknod() 
and similar

Environment:
Linux jessie64 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 
(2018-01-08) x86_64 GNU/Linux
Checked against latest coreutils version.


[Message part 3 (message/rfc822, inline)]
From: Pádraig Brady <P <at> draigBrady.com>
To: Declercq Laurent <l.declercq <at> nuxwin.com>, 30534-done <at> debbugs.gnu.org
Subject: Re: bug#30534: cp - Possible bugs when not preserving mode (explicit)
 and when copying special files
Date: Sat, 24 Feb 2018 18:24:17 -0800
On 20/02/18 00:04, Declercq Laurent wrote:
> Le 20/02/2018 à 04:26, Pádraig Brady a écrit :
>>> 2. Non-permission bits are preserved, even when the --no-preserve=mode
>>> option is involved.
>>>
>>> Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
>>> cp(1) command (run as root user): cp -r --no-preserve=mode spfile
>>> spfile_copy
>>>
>>> Current result:
>>>
>>> prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy
>> I'm not seeing this. I get 'x' rather than 's' here (and '-' with the fix)
>>
>>> Expected result (considering UMASK 0022 and without the first bug above):
>>>
>>> prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy
>> thanks!
>> Pádraig
>>
> 
> I'll make a new try, providing you relevant STRACE(1) output if necessary.
> 
> Thank you for your fast reaction.
> 

I've pushed this fix.

Whether setuid is cleared may be file system dependent.
set_acl() corresponds to a setxattr() here,
and that was enough to clear the setuid perm on various
file systems here at least.

We can expand on this in future if needed,
which would be better as a separate patch anyway.

cheers,
Pádraig.


This bug report was last modified 7 years and 121 days ago.

Previous Next


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