bug#31675: Existing directories and files permissions are not being kept intact

[Pádraig Brady]

On 03/06/18 15:30, Gunjan Gupta wrote:
> ++ bugs mailling list
> 
> On Mon 4 Jun, 2018, 3:59 AM Gunjan Gupta, <address@hidden> wrote:
> 
>> No cpvdidnt created that directory. Directory was existing on the machine
>> before.
>>
>> It used to be fine before 8.26 version of coreutils and we use to supply
>> patches to our customer that use to use cp to copy files to the destination.
>>
>> Starting from 8.26, its broken. What will happen if we use the same
>> command to copy files to say /etc directory. I had one of our patch that
>> used to do that. I tried installing it on new system and whole system broke
>> because of this.
>>
>> Don't you think cp should preserve permissions for existing files and
>> directory? Using user's umask for new files sounds ok but why cp has to
>> change mode for existing files and directories?
>>
>> Is there a way I can tell cp to preserve destination permissions now?
>>
>> Thanks & Regards
>> Gunjan Gupta
>>
>> On Mon 4 Jun, 2018, 3:50 AM Pádraig Brady, <address@hidden> wrote:
>>
>>> tag 31675 notabug
>>> close 31675
>>> stop
>>>
>>> On 31/05/18 20:50, Gunjan Gupta wrote:
>>>> Hi,
>>>>
>>>> Suppose I have the following directory structure
>>>>
>>>> /
>>>> | - destination (mode=0755)
>>>>      | - dir (mode=0755)
>>>>           | - file.txt (mode=0644)
>>>> | - source
>>>>      | - dir (mode=0755)
>>>>           | - file.txt (mode=0644)
>>>>
>>>> My user has a umask of 0077. Now if I run the following cp command
>>>>
>>>> cp -aR --no-preserve=mode /source/* /destination
>>>>
>>>> I think the mode of destination/dir should stay as 0755 but it changes
>>> to
>>>> 0700. Is this expected?
>>>>
>>>> I am using coreutils 8.26-3 on Debian Stretch
>>>
>>> This is a little surprising as cp didn't create /destination/dir in this
>>> case.
>>> However if it did create that dir, then the mode would be expected.
>>> So cp is keeping the destination consistent whether it previously existed
>>> or not.

Actually looking more, this is a relatively recent change:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.19-145-g24ebca6

Also in retrospect, using --no-preserve=mode should
have no guarantees on the mode bits of the destination.
So it's probably best to leave existing mode bits in place.

Let me see if I can come up with a patch...

thanks,
Pádraig