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.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_copyI'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_copythanks! PádraigI'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.
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.