GNOME Bugzilla – Bug 535124
umask 002 not being applied for new directories, new files get the correct umask
Last modified: 2018-02-16 16:05:55 UTC
Please describe the problem: When I set the global umask in "/etc/X11/Xsession.d/56umask" to 002, new folders do not get created with the correct permissions, but with the default umask 022. This is an important issue for using gnome on a network. Steps to reproduce: 1. Set the global umask to 002, for example add "umask 002" in "/etc/X11/Xsession.d/56umask" 2. Re-Login. The umask should be active. Check in a terminal. 3. Create a new File with Nautilus: The file gets created with the correct permissions: -rw-rw-r-- 1 schnitzer users 0 2008-05-27 19:22 neue Datei 4. Create a new Directory with Nautilus: The dir gets creates with the wrong permissions: drwxr-xr-x 2 schnitzer users 4096 2008-05-27 19:18 Namenloser Ordner/ Actual results: The wrong umask is applied to the newly created directory Expected results: A directory with the permissions: drwxrwxr-x 2 schnitzer users 4096 2008-05-27 19:18 Namenloser Ordner/ should be created. Does this happen every time? Yes Other information: This could be related to bug #459734 (gnome-commander) Maybe this is a GIO issue.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 516429 ***
I think that, this is not a dupe. This is specific to Nautilus 2.22. 1.) It creates new files with the correct permissions 2.) But does not use the umask for new directories
I've the same bug with Nautilus 2.22.3 Like Dominik said, I don't think it's a dupe. The files are ok, but not the directories.
Confirming, reassigning to gio. In glocalfile.c:g_local_file_make_directory(), local directories are created with g_mkdir (local->filename, 0755) Maybe it should be g_mkdir (local->filename, 0777) instead. This would be analogous to glocalfileoutputstream.c:_g_local_file_output_stream_replace() which uses a 0666 mode for files by default.
I can confirm that this fixes the problem.
could any of the maintainers comment on the suggested change?
The umask fix seems correct to me; I'd love to get an ack from a GLib maintainer as we intend to include it in Debian.
Created attachment 116066 [details] [review] Use 0777 instead of 0755 as umask
g_local_file_make_directory is broken indeed. It will always remove write bits for group and others, regardless of the umask. The same problem is visible when a local directory is created with Bluefish (the Bluefish development tree also uses GIO/GVFS). The suggested change is correct and should be applied.
Yeah, I think this is right. The docs should probably gain some hints about the owners and modes of the created directories. Can you do that when you commit this patch ?
Created attachment 116124 [details] [review] Document that permissions of newly created local directories are the defaults of the process This is the proposed doc fix to g_file_make_directory() and g_file_make_directory_with_parents().
Umask fix committed as r7323 to trunk and r7324 to glib-2-16 2008-08-08 Loïc Minier <lool@dooz.org> Bug 535124 – umask 002 not being applied for new directories, new files get the correct umask * glocalfile.c: (g_local_file_make_directory): Use 0777 instead of 0755 as umask
thanks. Please commit the doc patch too.
Doc patch committed as r7330 to trunk (NB: not backported to glib-2-16 as the API documentation wasn't backported there): 2008-08-09 Loïc Minier <lool@dooz.org> Bug 535124 – umask 002 not being applied for new directories, new files get the correct umask * gfile.c (g_file_make_directory) (g_file_make_directory_with_parents): Document ownership and permissions of newly created directories as being the default ones of the process.
We are hitting this again, seems the fix here of creating with permissions of 0777 doesn't create the files with the umask permission set. I can reproduce this with the live-g-file test and setting any umask in the system.
After more debugging glib is not the one at fault. Sorry for the noise.