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.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#30534
; Package
coreutils
.
(Mon, 19 Feb 2018 17:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Declercq Laurent <l.declercq <at> nuxwin.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Mon, 19 Feb 2018 17:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#30534
; Package
coreutils
.
(Tue, 20 Feb 2018 03:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 30534 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#30534
; Package
coreutils
.
(Tue, 20 Feb 2018 08:05:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 30534 <at> debbugs.gnu.org (full text, mbox):
[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)]
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Sun, 25 Feb 2018 02:25:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Declercq Laurent <l.declercq <at> nuxwin.com>
:
bug acknowledged by developer.
(Sun, 25 Feb 2018 02:25:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 30534-done <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#30534
; Package
coreutils
.
(Sun, 25 Feb 2018 02:44:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 30534-done <at> debbugs.gnu.org (full text, mbox):
[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)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 25 Mar 2018 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.