Description of problem: The user umask setting is ignored by a gnome. If a user creates directories and files with nautilus or other Gnome GUI applications, for example, gedit, the user-specified umask is ignored and the system default umask is used. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux release 8.6 (Ootpa) How reproducible: Steps to Reproduce:- for a file === $ umask 0002 $ touch a $ ls -l total 1 -rw-rw-r--. 1 test1 test1 0 Sep 7 09:27 a $ nautilus <------ created an empty file here in the same directory and nautilus started from the same cli. $ ls -l total 11 -rw-rw-r--. 1 test1 test1 0 Sep 7 09:27 a -rw-r--r--. 1 test1 test1 0 Sep 7 09:30 'New Document' === for directory ~~~ $ umask 0002 And created a dir with correct permissions: $ mkdir 3T $ ls -lad drwxrwxr-x. 2 test1 test1 6 Sep 7 09:26 3T If the user starts nautilus in the GUI and creates the folder 4F, it was set with the wrong permissions: drwxr-xr-x. 2 test1 test1 6 Sep 7 09:27 4F ~~~ lab details credential:-- Host IP:- 10.74.249.205 username: passed ==> test1:redhat root: redhat Actual results: Permissions of both the files generated from cli and from nautilus are not the same. Expected results: Permissions of both the files/directory generated from cli and from nautilus should be the same, as set by the umask setting. Additional info: it works perfectly in CLI) Duplicate bug:- https://bugzilla.redhat.com/show_bug.cgi?id=1778579 After applying the advisory https://access.redhat.com/errata/RHSA-2020:4451 still, the issue is there, it can be reproduced.
I followed instructions from comment #0 with nautilus-3.28.1-20.el8.x86_64 and I've got the same result Only for files there was a difference: - when I used touch - -rw-rw-r--. - when I used gedit to create new file then I've got -rw-r--r--. - when I used New Document (from templates) in nautilus then it was created with -rw-------. also the permissions are the same if I start nautilus from terminal and from gui. For newly created folders: When created by mkdir - drwxrwxr-x. When created from nautilus started in terminal - drwxrwxr-x. (same as touch) When created from nautilus started in GUI - drwxr-xr-x. I tried to to use different umask (0006) and it worked the same. It seems that gui applications have another umask set somewhere, because gedit and nautilus started from gui are creating files with umask 0022 but both applications started from terminal return files with umask set in that terminal.
I see several things here: 1) The fact that Nautilus and possibly other applications create files from templates with private permissions: This seems to be a GLib2 regression caused by a fix for Bug 1722101. The following upstream patch is needed to make that work again: https://gitlab.gnome.org/GNOME/glib/-/commit/53f6ede62819fca7082e7cc1ed89edb799991f9a. 2) The fact that Nautilus started from the terminal, when another Nautilus instance is already running, doesn't honor umask cmd from that terminal: Nautilus (and some other applications) doesn't allow multiple processes, just opens a new window in the existing process and thus inherits the previous umask settings. This is expected. As a workaround you can use "pkill nautilus; nautilus". 3) The fact that the application started from GUI as mentioned by Petr doesn't honor umask cmd from some terminal: This is expected behavior, the `umask` cmd doesn't change the settings system-wide, but just for the concrete terminal. Given the fact that 2) and 3) are expected behavior, I would suggest moving this under the glib2 component...
So this is just a request to backport https://gitlab.gnome.org/GNOME/glib/-/commit/53f6ede62819fca7082e7cc1ed89edb799991f9a?
I think so, possibly some other commits from https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1134/.
So what happens in Fedora 37 is this: -rw-r--r--. 1 mcatanzaro mcatanzaro 0 Nov 14 11:10 'Empty Document created by touch' -rw-r--r--. 1 mcatanzaro mcatanzaro 0 Dec 22 2013 'Empty Document created by nautilus running in terminal' -rw-r--r--. 1 mcatanzaro mcatanzaro 0 Dec 22 2013 'Empty Document created by nautilus running outside terminal' drwxr-xr-x. 1 mcatanzaro mcatanzaro 0 Nov 14 11:10 'new dir created by mkdir' drwxr-xr-x. 1 mcatanzaro mcatanzaro 0 Nov 14 11:10 'new dir in terminal' drwxr-xr-x. 1 mcatanzaro mcatanzaro 0 Nov 14 11:11 'new dir outside terminal' which looks nice and consistent, permissions are the same regardless of how the file or directory is created. (The timestamp comes from whenever I created '~/Templates/Empty Document' in my home directory.) Now, I backported the first two commits from glib!1134 to RHEL 8 and got this: -rw-rw-r--. 1 mcatanzaro mcatanzaro 0 Nov 14 08:28 'Empty Document created by nautilus running in terminal after backport' -rw-------. 1 mcatanzaro mcatanzaro 0 Nov 14 08:28 'Empty document created by nautilus running in terminal before backport' -rw-r--r--. 1 mcatanzaro mcatanzaro 0 Nov 14 08:28 'Empty Document created by nautilus running outside terminal after backport' -rw-------. 1 mcatanzaro mcatanzaro 0 Nov 14 08:28 'Empty Document created by nautilus running outside terminal before backport' -rw-rw-r--. 1 mcatanzaro mcatanzaro 0 Nov 14 11:16 'Empty document created by touch' Notice that after backport, the permissions are different depending on whether nautilus was launched by gnome-shell (outside terminal) or within gnome-terminal, so that's pretty confusing. Then for directories: drwxrwxr-x. 2 mcatanzaro mcatanzaro 6 Nov 14 11:16 'New dir created by mkdir' drwxrwxr-x. 2 mcatanzaro mcatanzaro 6 Nov 14 11:17 'New dir created by nautilus running in terminal after backport' drwxrwxr-x. 2 mcatanzaro mcatanzaro 6 Nov 14 11:18 'New dir created by nautilus running in terminal before backport' drwxr-xr-x. 2 mcatanzaro mcatanzaro 6 Nov 14 11:17 'New dir created by nautilus running outside terminal after backport' drwxr-xr-x. 2 mcatanzaro mcatanzaro 6 Nov 14 11:19 'New dir created by nautilus running outside terminal before backport' The backport makes no difference here. I do think things look better overall after the backport, but it's still going to be confusing and doesn't really match the requested behavior IMO. IMPORTANT: In Fedora, the default umask is 0022. In RHEL 8, it is 0002.
Hmm, to make that consistent, https://github.com/systemd/systemd/pull/15318 is probably needed as well.
(In reply to Ondrej Holy from comment #8) > Hmm, to make that consistent, https://github.com/systemd/systemd/pull/15318 > is probably needed as well. Sure, it makes sense and the patch looks quite simple. Could you open a bug for systemd?
Very interesting. I'm willing to apply the fix for the GLib side of this, then.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (glib2 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:3005