--- Begin Message ---
Subject: |
cp - Possible bugs when not preserving mode (explicit) and when copying special files |
Date: |
Mon, 19 Feb 2018 11:22:48 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
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.
--- End Message ---
--- Begin Message ---
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.
--- End Message ---