Subject: bug#30534: closed (Re: bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 25 Feb 2018 02:25:02 +0000

Your bug report

#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
30534: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30534
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files
From: Pádraig Brady <[email-masked]>
To: Declercq Laurent <[email-masked]>, [email-masked]
Date: Sat, 24 Feb 2018 18:24:17 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Subject: cp - Possible bugs when not preserving mode (explicit) and when copying special files
From: Declercq Laurent <[email-masked]>
To: [email-masked]
Date: Mon, 19 Feb 2018 11:22:48 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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.