GNOME Bugzilla – Bug 109176
make_directory and umask
Last modified: 2008-09-06 19:17:35 UTC
This is sort of a doc bug, sort of an API bug. The GNOME VFS docs say nothing about the interaction of make_directory() with the umask. Isn't that just a UNIX file system detail? Well, yes it's a UNIX file system detail, but no, because it affects the what permissions you pass in. You need to pass in GROUP_ALL because 0775 should be the directory mask on operating systems like Red Hat linux using a user-private-group scheme. But you might think that was unsafe on systems that I think there probably should be a predefined define for the value: GNOME_VFS_PERM_USER_ALL | GNOME_VFS_PERM_GROUP_ALL | GNOME_VFS_PERM_OTHER_READ | GNOME_VFS_PERM_OTHER_EXEC (0775) since it virtually always is the value you want here: - You want group all as discussed above - But you shouldn't have OTHER_ALL because if you create network directories, on systems without the concept of umask, you don't want them world writable. (Systems without umask probably don't don't have groups) Actually, most of the GNOME vfs modules just ignore the permissions field, but I still wouldn't feel safe passing in OTHER_ALL. Anyways, the docs need to discuss this issue at a minimum.
"But you might think that was unsafe on systems that" This got cut of. I'm not sure what you meant. What exactly is it you want documented? make_directory for local files does use mkdir, so it follows umask. For remote files the umask currently doesn't affect anything. I agree with wanting the define though. Just need to come up with a good name for it. GNOME_VFS_PERM_DIRECTORY_DEFAULT?
"on systems that don't use user private groups" - that is, on a standard Unix system, creating a directory with permissions 0775 would allow it to be written to be all other users on the system, since everybody is typically in a 'users' group. I basically would want documented: "for some backends the permissions passed in will be modified by system policy. For instance, for the file backend, the current umask is AND'ed with the permissions passed in to give the actual permissions used. In general, you should use GNOME_VFS_PERM_DIRECTORY_DEFAULT for the permission field; other values may produce unexpected results due to differences between backends." (Or you could explain more about the reasoning behind DIRECTORY_DEFAULT)
I was recently surprised by the file chooser creating a directory with different permissions than mkdir does. As an example: jonathan@neokiwi:~$ mkdir mkdir jonathan@neokiwi:~$ ls -ld mkdir drwxr-xr-x 2 jonathan jonathan 4096 2004-08-28 11:19 mkdir/ (make a directory with the file chooser) jonathan@neokiwi:~$ ls -ld chooser drwxr-xr-- 2 jonathan jonathan 4096 2004-08-28 11:22 chooser/ And just for comparison, I also made a directory with nautilus: jonathan@neokiwi:~$ ls -ld nautilus drwxr-xr-x 2 jonathan jonathan 4096 2004-08-28 11:23 nautilus/ I think that using the chooser should result in the same set of permissions as the "normal" means of creating directories. Version info: jonathan@neokiwi:~$ pkg-config --modversion libgnome-2.0 2.6.1.2 I am using the packages currently in Debian unstable.
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome. If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs. @Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together. General further information: http://en.wikipedia.org/wiki/GVFS Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html