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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30534 in the body.
You can then email your comments to 30534 AT debbugs.gnu.org in the normal way.

the display of automated, internal messages from the tracker.

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

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: 2018年2月19日 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 #8 received at 30534 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Declercq Laurent <l.declercq <at> nuxwin.com>, 30534 <at> debbugs.gnu.org
Subject: Re: bug#30534: cp - Possible bugs when not preserving mode (explicit)
 and when copying special files
Date: 2018年2月19日 19:26:46 -0800

[Message part 1 (text/plain, inline)]

On 19/02/18 02:22, Declercq Laurent wrote:
> 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.
Thanks for the clear details.
The attached should fix this up.
> 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

[cp-default-perms.patch (text/x-patch, attachment)]

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

From: Declercq Laurent <l.declercq <at> nuxwin.com>
To: Pádraig Brady <P <at> draigBrady.com>, 30534 <at> debbugs.gnu.org
Subject: Re: bug#30534: cp - Possible bugs when not preserving mode (explicit)
 and when copying special files
Date: 2018年2月20日 09:04:49 +0100

[Message part 1 (text/plain, inline)]

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.

[l_declercq.vcf (text/x-vcard, attachment)]

Message #16 received at 30534-done <at> debbugs.gnu.org (full text, mbox):

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: 2018年2月24日 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.

Message #19 received at 30534-done <at> debbugs.gnu.org (full text, mbox):

From: Declercq Laurent <l.declercq <at> nuxwin.com>
To: Pádraig Brady <P <at> draigBrady.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: 2018年2月25日 03:42:57 +0100

[Message part 1 (text/plain, inline)]

Le 25/02/2018 à 03:24, Pádraig Brady a écrit :
> 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.
That is exactly what a strace showed me: setxattr() doesn't remove 
non-permission bits while with the explicit no-preserve=mode option, we 
could expect them to goes away.
From my point of view, there should be a new option, allowing us to 
explicitely discard ACL too, eg: no-preserve=mode,acl and then, enforce 
usage of chmod in such a case instead of relying on setxattr(). That is 
just an idea through, that would make us able to not break old behavior 
for those relying on it.
Yes, that is system dependent. Should I create another issue for that issue?
Anyway, thank for your involvement here. That is much appreciated.
-- 
Laurent Declercq
iHMS/i-MSCP CEO & Lead Developer
------------------------------------------------------------------------
This message and any attachment are intended solely for the addressees 
and are
confidential. iHMS/i-MSCP, including any part representing these 
entities may
not be held responsible for their contents whose accuracy and 
completeness cannot
be guaranteed over the Internet. Unauthorized use, disclosure, 
distribution, copying,
or any part thereof is strictly prohibited. If you are not the intended 
recipient of
this message, please notify the sender immediately and delete it.
------------------------------------------------------------------------

[Message part 2 (text/html, inline)]

[l_declercq.vcf (text/x-vcard, attachment)]

Previous Next

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