GNOME Bugzilla – Bug 758066
'dconf update' changes permissions if umask is set
Last modified: 2018-09-21 16:15:48 UTC
Created attachment 315420 [details] [review] Restore permissions on changed files Hi, I've got downstream report which says that when 'dconf update' is called after umask has been changed to e.g. 077 then files updated by this call have changed permissions (to 600 on the /etc/dconf/db/local in this specific report). The function which changes the permissions is the g_file_set_contents() from gvdb_table_write_contents() because it creates temporary file with the new contents and then renames it to the resulting one. Since the function updates contents of the file and is not primarily for creating of new file I guess that the resulting file should have the same permissions as the original one. Could we restore the permissions after the contents has been written? Moreover, shouldn't we set the permissions to at least 644 by default (on files under /etc/dconf/db/)? Attached is a patch which restores the permissions. Regards Marek
Does this looks like a bug to you or is the current behaviour intentional?
Hi, I would like to resolve this downstream but I don't want to diverge from upstream. Do you think that the patch is appropriate or it should stay as it is? Regards
As a extra datapoint - we have seen the same on openSUSE/SLED. On request from our SLED people, we have just applied the patch from reporter.
Review of attachment 315420 [details] [review]: Hi Marek. The patch works perfectly for existing files. However in case a db file is missing (e.g. deleted by hand), 'dconf update' regenerates the file and still set its permission to 0600. IMHO in this case we should set it to 0644 as you have previously suggested.
Created attachment 347082 [details] [review] Restore permissions on changed and missing files Based on Marek's patch.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dconf/issues/25.