Nautilus and other gnome apps using incorrect umask for new directories

Bug #242618 reported by 3point2
36
This bug affects 1 person
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://bugzilla.gnome.org/show_bug.cgi?id=535124 that seems to be the cause of this problem, along with a suggested solution.
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

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for your bug report, no need to report upstream bugs on launchpad though

Changed in glib2.0:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Changed in glib:
status: Unknown → Confirmed
Revision history for this message
Valentijn Sessink (valentijn) wrote :

I'm a bit confused by your comment; setting importance to "low" seems to imply that a fix will be in the next Gnome - which means Ubuntu 8.10. Or am I mistaken here?
This bug is too important for that: network users should be able to rely on the correct rights for their new directories - you can't have an LTS release that applies the incorrect rights to new directories for 5 years.

Besides, the fix is trivial (see Gnome bugzilla):
@@ -1974,7 +1981,7 @@
 {
   GLocalFile *local = G_LOCAL_FILE (file);

- if (g_mkdir (local->filename, 0755) == -1)
+ if (g_mkdir (local->filename, 0777) == -1)
     {
       int errsv = errno;

This should be added to the /debian/patches dir (and I'm not sure how to get it there - is Debian bug tracking the right place?

Revision history for this message
3point2 (basil-existanze) wrote :

I agree that this bug should have a slightly higher priority: it's also a regression from previously correct behaviour. We are in an office environment where collaboration and sharing files over the network are core to our functioning. Since upgrading from Feisty (7.04), we're having problems every time someone creates a new folder in our sshfs mounted share.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the importance doesn't determine the version where it'll be fixed and it's low because you are the only one who opened a bug about the issue so far so it doesn't seem to a priority for users, the bug also maybe lacks an explanation of why that should be considered as an important issue, describing your usecase scenario could be a good idea there

Revision history for this message
3point2 (basil-existanze) wrote :

My usage scenario: A server contains a directory owned by group 'collab', which is group writeable and has the setgid bit set. This means that all new directories created underneath it will also be owned by group 'collab'. The server is set up with accounts for users whose desktop systems automatically mount this directory using sshfs so that it appears on their local desktop. The idea is that everyone who is in the 'collab' group on the server should be able to add and delete files and directories from this folder. The umask on each user's desktop system must be set to create all new files and directories group-writeable, which this bug prevents from happening correctly. As a result, a new directory created by a user using Hardy isn't writeable by the other members of the 'collab' group until the group permission is manually corrected. Please let me know if anything here doesn't make sense. I think it's a fairly sensible usage scenario.

Revision history for this message
Sebastien Bacher (seb128) wrote :

right, that makes sense and I think the issue should be fixed to hardy, I would like to get upstream to comment on the code change before having it used for a stable update though

Revision history for this message
on5sl (on5sl) wrote :

I agree with Valentijn Sessink. This bug should get a higher priority.

Revision history for this message
Petr Stehlik (pstehlik) wrote :

Sebastien, do you really want more people to open the same bug to increase priority of this? It is really a problem for many people - for example imagine two (or more) users sharing the same computer - they can't even sort out photos or music or anything (if one creates a folder with common files like photos or music the others can't rename or delete files in that folder).

Besides that, #241198 looks very much like duplicate of this bug so more people are suffering, including me and my friends that I convinced to switch from Windows to Ubuntu..

And there are more:
http://brainstorm.ubuntu.com/item/200/
https://answers.launchpad.net/ubuntu/+source/nautilus/+question/36843

I would really like to see this fixed ASAP as it's clearly a bug that makes using the computer cumbersome (which is not what Ubuntu is about, I believe).

Thanks!

Revision history for this message
Sebastien Bacher (seb128) wrote :

discussing the settings if of no use, the issue has been confirmed and is waiting for an upstream comment on the change, adding noise to the bug will not make it be fixed quickly if the issue is just that people are busy, you can try to comment on bugzilla though

Changed in glib2.0:
importance: Low → Medium
Revision history for this message
ak4life (ubunut-ak4life) wrote :

Another vote for getting this bug fixed ASAP.. It's quite a big deal for us as we are essentially unable to use Nautilus to work with shared folders..

Revision history for this message
schola (schola) wrote :

I changed my desktop environment because of this bug. Gnome has had problems with umask for years. The only reasons, for such a basic bug still being an issue, can be really bad coders or sabotage. I am so annoyed by this kind of bugs!
Sorry for ranting but it took me a whole day. I would also like to see this fixed.

Revision history for this message
Sebastien Bacher (seb128) wrote :

those comments are not really constructive, there is just lot of bugs and not a lot of users who have issues to the umasks not correctly being set so the bug is somewhat not really noticed by people working on those applications, I've added a comment upstream asking if they can review the suggested change

Revision history for this message
Green Fish (lgardent) wrote :

Hello,

Ok so I am in the exact same situation as Petr Stehlik. I just managed to convert a whole family from windows media center to ubuntu hardy, and they need a big shared directory where all users in the same group "users" may share stuff (pictures, music, and so on). Umask in /etc/profile is set to 002 instead of the default 022 ; it therefore work fluently in a term, nautilus won't take the new umask into account.

After spending so much time and energy explain how Ubuntu & gnome are so nice and easy to use, I feel utterly stupid having to say to them that this isn't possible because of a bug in gnome pending for the past 3 years or so.

What am I supposed to do ? switch to KDE ?

This is absurd. Please fix.

Thank you for all your work and efforts.
Cheers

Revision history for this message
Wouter Hanegraaff (wouter-openoffice) wrote :

You can add the following line to your sources.list if you want a patched version:

deb http://backports.openoffice.nl hardy-openoffice glib2.0

Packages is this repository can be gpg authenticated. The key that is being used for signing the packages is <email address hidden>. You can enter this key into the APT trusted keys database with the following command:
wget http://<email address hidden> -O- | sudo apt-key add -

Use at your own risk, etc. etc.

To create these packages, I simply downloaded the latest version from hardy-updates and applied the following patch:

--- gio/glocalfile.c.orig 2008-08-07 12:33:40.000000000 +0200
+++ gio/glocalfile.c 2008-08-07 12:33:53.000000000 +0200
@@ -1985,7 +1985,7 @@
 {
   GLocalFile *local = G_LOCAL_FILE (file);

- if (g_mkdir (local->filename, 0755) == -1)
+ if (g_mkdir (local->filename, 0777) == -1)
     {
       int errsv = errno;

I'll try to keep this repository updated if new packages are uploaded to hardy-updates without this fix. Any new version from ubuntu will overwrite my packages, so let's hope the next version in hardy-updates has this fix applied so I won't have to create another patched package.

Wouter

Revision history for this message
Sebastien Bacher (seb128) wrote :

installing non official packages can be a security issue, create other bugs and break next official updates so I would recommend users to wait for an official update rather than adding random apt sources

Revision history for this message
Green Fish (lgardent) wrote :

Thanks Wouter! even if I actually ended up rebuilding the glib package from source packages on my own.

Sebastien Bacher > of course, but for the people who actually need this feature and can't wait another couple of months/years for ubuntu maintainers 1) get interested in fixing the bug 2) actually make a move, it is rather good news that someone released a fixed package. :)

(absolutely no harsh feelings towards the ubuntu team, they do a wonderful job. it's just that sometimes reactivity needs a little push)

Revision history for this message
Wouter Hanegraaff (wouter-openoffice) wrote : Re: [Bug 242618] Re: Nautilus and other gnome apps using incorrect umask for new directories

Hi,

> installing non official packages can be a security issue, create other
> bugs and break next official updates so I would recommend users to wait
> for an official update rather than adding random apt sources

Fine, let's just wait some more time until someone does something some
time soon. If the problem is ignored long enough, the users affected
will go away eventually and stop complaining or worse, trying to "help".

Wouter

Changed in glib2.0:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in glib2.0:
status: Confirmed → Fix Committed
Revision history for this message
Adam Reeve (adreeve) wrote :

Thanks,

I've enabled the proposed repositories and it works well for me now.

Revision history for this message
Green Fish (lgardent) wrote :

seems to have been accepted in ubuntu updates. Many thanks for solving the bug !

Changed in glib:
status: Confirmed → Fix Released
Revision history for this message
Petr Stehlik (pstehlik) wrote :

Martin, I have just tested it and it works great. Thanks a lot to everybody involved for fixing it.

BTW, will this be distributed via the regular security updates or do I need to enable the proposed updates to everyone affected by this bug?

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 242618] Re: Nautilus and other gnome apps using incorrect umask for new directories

Hi Petr,

Petr Stehlik [2008-08-13 22:24 -0000]:
> Martin, I have just tested it and it works great. Thanks a lot to
> everybody involved for fixing it.

Thanks!
> BTW, will this be distributed via the regular security updates or do I
> need to enable the proposed updates to everyone affected by this bug?

Not hardy-security, but hardy-updates. Both are enabled by default.
It'll move from proposed to updates soon.

Revision history for this message
Lutfi (lutfiarab) wrote :

Hi. I'm also want to try this update. But i need individual package name. Could you tell me what packages name i have to install?

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is a new version in intrepid which fixes the issue

Changed in glib2.0:
status: Triaged → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in glib2.0:
status: Fix Committed → Fix Released
Revision history for this message
Günter (guenter-grodotzki) wrote :

when switching terminal (ctrl + alt + f1)
$ umask
0002

in gnome-terminal:
$ umask
0022

checked:
- login.defs
- profile/.profile
- .basrc

using libpam-umask for the settings.

nautilus does not obey the umask either.

Revision history for this message
Lutfi (lutfiarab) wrote :

I am not sure this also related bug on this case or not. Here i make the files on my dekstop:

lutfi@lutfi-desktop:~$ ls -l Desktop/
total 4
drwxrwxr-x 2 lutfi Domain Users 4096 2008-09-03 04:56 directory
-rw-rw-r-- 1 lutfi Domain Users 0 2008-09-03 04:56 file

I am use umask 0002 on /etc/profiles. And it is OK with umask now. Thanks anybody :-D

Problem come from ownership of my files after copy/move to NFS server. These compare copy and move using gnome and terminal.

Copy is OK. Because copy make new file/directory on NFS server. And the ownership is same with NFS server. Ownership change from my Desktop "lutfi.Domain Users" to be "lutfi.mis" on NFS server.

But why for moving from desktop using gnome have different ownership with moving using terminal? Gnome give permission "lutfi.mis" (change on server directory only. file no problem) and terminal still have my original permission "lutfi.Domain Users" (both directory and file).

So? Why moving files with nautilus have different result with terminal?

lutfi@lutfi-desktop:~$ ls -l /rsisvr/division/mis/gnome-test/*
/rsisvr/division/mis/gnome-test/cp-from-gnome:
total 4
drwxrwxr-x 2 lutfi mis 4096 2008-09-03 04:52 directory
-rw-rw-r-- 1 lutfi mis 0 2008-09-03 04:52 file

/rsisvr/division/mis/gnome-test/cp-from-terminal:
total 4
drwxrwsr-x 2 lutfi mis 4096 2008-09-03 04:51 directory
-rw-rw-r-- 1 lutfi mis 0 2008-09-03 04:51 file

/rsisvr/division/mis/gnome-test/mv-from-gnome:
total 4
drwxrwxr-x 2 lutfi mis 4096 2008-09-03 04:52 directory
-rw-rw-r-- 1 lutfi Domain Users 0 2008-09-03 04:52 file

/rsisvr/division/mis/gnome-test/mv-from-terminal:
total 4
drwxrwxr-x 2 lutfi Domain Users 4096 2008-09-03 04:48 directory
-rw-rw-r-- 1 lutfi Domain Users 0 2008-09-03 04:48 file

Changed in glib:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.