Nautilus and other gnome apps using incorrect umask for new directories
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GLib |
Fix Released
|
Medium
|
|||
glib2.0 (Ubuntu) |
Fix Released
|
Medium
|
Ubuntu Desktop Bugs | ||
Hardy |
Fix Released
|
Low
|
Ubuntu Desktop Bugs |
Bug Description
This affects Ubuntu Hardy (8.04)
To replicate this bug, set umask in /etc/profile to something *less* restrictive than the default 022. I'm trying to use 002 in order to have users create group writeable files in an office collaboration environment. Log out and in again for the change to take effect. touch-ing and mkdir-ing from the command line should create files and directories with the correct permissions. Next, in Nautilus, try create a new empty file and a new folder. The empty file will have the correct permissions, whilst the directory will have permissions of 755.
Note that changing the umask to something *more* restrictive, e.g. 077 seems to work correctly.
There is a gnome bug filed at http://
I was unable to reproduce this on Feisty (7.04)
TESTCASE:
- edit /etc/profile and set the umask to 002
- restart the session
- create a new directory in nautilus, look at the permissions, notice that the group can't write there
- install the new libglib, restart the session
- create a new directory in nautilus, look at the permissions, notice that the group can write there now
Related branches
Changed in glib: | |
status: | Unknown → Confirmed |
Changed in glib2.0: | |
assignee: | nobody → desktop-bugs |
importance: | Undecided → Low |
status: | New → Confirmed |
description: | updated |
Changed in glib: | |
status: | Confirmed → Fix Released |
Changed in glib: | |
importance: | Unknown → Medium |
thank you for your bug report, no need to report upstream bugs on launchpad though