why resets `desktop-file-edit` the permissions of a file?

Question

let's say i have set the umask system-wide to 027 via a one-liner at /etc/profile.d/ on a multiuser-system. after some time resp. reboots i want to hide an existing desktop-file system-wide from the menu with the following commands:

# just in case the folder doesn't exist, create it:
sudo install -o root -g root -m 755 -p -d '/usr/local/share/applications/'

# copy the existing desktop file and preserve all attributes (which are permissions 644 for the old & new file):
sudo cp -vi --preserve=all '/usr/share/applications/application.desktop' '/usr/local/share/applications/'

# add or change the existing key to true:
sudo desktop-file-edit --set-key=NoDisplay --set-value=true '/usr/local/share/applications/application.desktop'

it kind of works, but not as intended: if you open alacarte this desktop-file is still activated but not shown in the menu!
with a closer look at /usr/local/share/applications/ the reason can be found... the permissions of application.desktop are 640 instead of 644, so the file would still be shown but it can't be read by the normal user and hence it doesn't show up in the menu (and therefore the correctly set NoDisplay=true does not really mater in this case).

i even tried to the add the option -m 644 mentioned at the man page, but it seems to be exclusively for desktop-file-install.

1. is this behavior intended? and if so, why?
2. is there an easy workaround instead of using an appended chmod?
3. why does editing a file, change the permissions of it at all?!?

Answer 1

why does editing a file, change the permissions of it at all?!?

There are a few ways to edit a file:

1. Read data, apply updates, write new data on top, hope nobody pulls the power plug mid-way.
2. Read data, apply updates, write old data to a backup file, write new data on top of the existing file, delete the backup if everything went well.
3. Read data, apply updates, move the old file aside, create a new one in its place, write new data there, delete the original if everything went well.

desktop-file-edit uses the 3rd method. This method, which involves replacing the old file with a new one, requires the program to manually reapply (copy) all metadata such as file ownership or permissions from the old file to the new one. The program doesn't do that, and as a result, the updated file has the "default" inherited ownership and permissions instead.

is there an easy workaround instead of using an appended chmod?

Prepend a umask 022 instead.