GNOME Bugzilla – Bug 327249
nautilus ignores umask
Last modified: 2007-01-11 11:38:25 UTC
Fordwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314796 Hi, while trying to set a global umask for my users via gdm, I discovered that nautilus simply refuses to use any umask. Even when the session's umask is set to something non default and other gnome programs obey it (gedit, evolution,...), nautilus keeps on creating files with 600 as permissions. This makes it impossible to use nautilus in a network environment with shared folders. Thanks for your tremendeous work, /////// I've tested this on nautilus 2.12, creating a .gnomerc with the needed umask, but nautilus always uses 600 as umask.
Thanks for your bug report! I'm reassigning this to GnomeVFS. We're hard-coding 0666 in gnome-vfs-xfer.c:xfer_create_target which is passed to gnome_vfs_create_uri, pass 0600 to fchmod in gnome-vfs-private-utils.c:gnome_vfs_create_temp, and pass 0777 to gnome_vfs_make_directory_for_uri in gnome-vfs-xfer.c:create_directory. I think what permissions are used should be decided inside GnomeVFS. Maybe we should pass umask permissions, and the modules should decide whether they care or not.
Hi, is anybody going to fix this bug? From my point of view, it is making GNOME/nautilus unusable in the group/corporate environment- users can't share directories and files. Am I right? Though, I believe that GNOME/nautilus is used for sharing files among users. Could you give me a tip how to do that? Thank you, Vaclav Svatek.
Is there any workaround for this? There are people using GNOME in big organisations. How do they cope with this?
You can try to use webdav for that purpose. This is how gnome-user-share works, but it is really hard to use as very slow even in local, and most of GNOME apps do not support dav:// protocols (eg. I cannot open my pictures shared in a local folder via gthumb in Nautilus, I have first to copy the files to open them or have to use davfs2 to mount local shared folders which again has some limits... Really, this bug should be fixed for the next GNOME release, as it prevents GNOME/nautilus use not in big organizations as said before, but also for simple (shared pictures, music etc.) Cheers, Julien
I now have 2 different corporate customers who are being affected by this problem. A bugfix would be great. :)
I just posted a bounty on this issue. Anyone want to make a quick $250 USD, jump on it: https://launchpad.net/bounties/nautilus-ignores-umask
Created attachment 70155 [details] [review] Fix for nautilus 2.14.1 Here is a simple fix. The initial analysis turned out wrong, this is a nautilus bug. Copying a temporary file will result in the file creating with paranoid permissions, like those of a temporary file.
If it works, it will definitely be eligible for the bounty. Is this going to find it's way into current official Ubuntu and Debian repositories, so that some future apt-get upgrade I do after patching doesn't undo everything? I realize that I can create a custom deb and pin it, but that doesn't seem nearly as clean as seeing the change roll into official production, especially given the nature of thie fix, and the problem that it solves.
I've just uploaded a patched package to Debian unstable.
Great! Thank you Josselin for your work. However, the patched nautilus package still does not follow the default posix ACL from the parent folder. Do you think it is possible to take this into account? Cheers, Julien
Maybe I should have been more precise: julien@hera:/home$ ls -ld partage/ drwxrwsr-x+ 2 root audio 4096 2006-08-04 07:20 partage/ getfacl partage/ # file: partage # owner: root # group: audio user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:other::r-x julien@hera:/home$ ls -l partage/ total 0 -rw-r--r-- 1 julien audio 0 2006-08-04 07:20 nouveau fichier -rw-rw-r-- 1 julien audio 0 2006-08-04 07:19 test In this case, test was created in command line through touch. "nouveau fichier" was created by nautilus thanks to the contextual menu "Create a document > Empty file" (or whatever it is called in English). Given the default ACL, all the files created under partage/ should be writable by the audio group, which is not the case with nautilus. Cheers, Julien
Julien, I think this is feasible but it requires more important changes to the code. We need to replace the call to nautilus_file_operations_new_file_from_template by direct calls to gnome_vfs_async_create_uri and gnome_vfs_async_write. This would also fix the umask bug in a more elegant way.
I wish I could write C and would do it myself ;-) Do you think someone will do that shortly? I thought fixing this umask bug would also fix this. I really think both issues are linked. cheers, Julien
Hi, I have built latest gnome-vfs which includes ACL support, and applied the patch from #62817 (http://bugzilla.gnome.org/attachment.cgi?id=63787 - which applies to nautilus package from Debian unstable), and this does not work neither (same behaviour as explained before). Should I open a new bug for this issue? Cheers, Julien
No, the issue is really the same, and the solution doesn't need any specific ACL support: nautilus shouldn't use a temporary file for the purpose of creating a file elsewhere, especially when gnome-vfs has all the functions to do that.
Hi Josselin, I applied the patch and I have some strange behavior. If I set an umask of 007, I get files with permissions 661, but I should be getting 660. I think the MODE XOR UMASK is not what you should do. I think it should be MODE AND !UMASK. Correct me if I am wrong. Thanks for your patch! Jaume
Created attachment 73864 [details] [review] Fix for nautilus 2.16.0 Of course, it indeed needs to be &, not ^.
Created attachment 74009 [details] [review] Real fix for nautilus 2.16.0 Ooops. This one was very wrong.
i noticed this bug isn`t fixed in the most recent nautilus versions.. perhaps forgotten?
Changing the umask like that is not threadsafe. If a gnome-vfs workerthread was creating a file at the same time it'd get 000 as permissions.
Using GNOME_VFS_XFER_TARGET_DEFAULT_PERMS in the gnome-vfs-xfer call in this case seems a better solution.
could you make a pactch file and attatch it here?
Created attachment 77992 [details] [review] Fix using target_default_perms This patch uses GNOME_VFS_XFER_TARGET_DEFAULT_PERMS instead. Julien, could you check whether it also fixes the problem with posix ACLs?
Hi, I have applied successfully this updated patch to Debian unstable 2.14.3 sources. Everything seems to work ok with Posix ACLs! Thank you very much for your work. Cheers, Julien
Commited. Thanks.