bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30534: cp - Possible bugs when not preserving mode (explicit) and wh


From: Declercq Laurent
Subject: bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files
Date: Sun, 25 Feb 2018 03:42:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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.

------------------------------------------------------------------------

Attachment: l_declercq.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]