2125184 – The user umask setting is ignored by gnome. If a user create directories and files with nautilus or other Gnome GUI applications, for example gedit, the users specified umask is ignored and the system default umask is used.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2125184 - The user umask setting is ignored by gnome. If a user create directories and files with nautilus or other Gnome GUI applications, for example gedit, the users specified umask is ignored and the system default umask is used.

Summary: The user umask setting is ignored by gnome. If a user create directories and ...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	glib2
Sub Component:
Version:	8.6
Hardware:	x86_64
OS:	Linux
Priority:	low
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Michael Catanzaro
QA Contact:	Tomas Pelka
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2022-09-08 09:07 UTC by Avinash Maske
Modified:	2023-06-09 06:42 UTC (History)
CC List:	7 users (show)
Fixed In Version:	glib2-2.56.4-160.el8
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2023-05-16 09:10:01 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	RHELPLAN-133509	0	None	None	None	2022-09-08 09:08:49 UTC
Red Hat Product Errata	RHBA-2023:3005	0	None	None	None	2023-05-16 09:10:03 UTC

Description Avinash Maske 2022-09-08 09:07:11 UTC

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.

Comment 3 Petr Schindler 2022-09-21 13:42:19 UTC

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.

Comment 4 Ondrej Holy 2022-11-11 09:16:54 UTC

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...

Comment 5 Michael Catanzaro 2022-11-11 17:10:50 UTC

So this is just a request to backport https://gitlab.gnome.org/GNOME/glib/-/commit/53f6ede62819fca7082e7cc1ed89edb799991f9a?

Comment 6 Ondrej Holy 2022-11-14 08:38:43 UTC

I think so, possibly some other commits from https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1134/.

Comment 7 Michael Catanzaro 2022-11-14 17:27:47 UTC

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.

Comment 8 Ondrej Holy 2022-11-15 08:25:43 UTC

Hmm, to make that consistent, https://github.com/systemd/systemd/pull/15318 is probably needed as well.

Comment 9 David Tardon 2022-11-15 12:41:20 UTC

(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?

Comment 10 Michael Catanzaro 2022-11-15 13:58:13 UTC

Very interesting. I'm willing to apply the fix for the GLib side of this, then.

Comment 24 errata-xmlrpc 2023-05-16 09:10:01 UTC

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

Note You need to log in before you can comment on or make changes to this bug.