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.

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