[debbugs-tracker] bug#30534: closed (cp - Possible bugs when not preserving mode (explicit) and when copying special files)

[GNU bug Tracking System]

Your message dated Sat, 24 Feb 2018 18:24:17 -0800
with message-id <address@hidden>
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
address@hidden)


-- 
30534: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30534
GNU Bug Tracking System
Contact address@hidden with problems
> --- 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 ---