GNOME Bugzilla – Bug 162617
Crash bug with restrictive permissions on /home
Last modified: 2011-02-04 16:17:29 UTC
If you do not have read permission in every directory leading up to the current working directory, Gimp will crash when attempting to traverse directories to save. An example of this: # chmod 711 /home $ cd ~/doc/img/ $ gimp example.xcf When clicking Save as, Gimp will complain that it cannot read /home (permission denied) and then cause a recursive call to malloc(). This will cause a coredump after a short time (Illegal instruction (core dumped)).
I can reproduce this but it's very likely a problem of the GtkFileChooser widget. There's a warning dialog that says: Could not retrieve information about file:///home/neo: Error opening directory '/home': Permission denied After accepting this message, the file-chooser comes up with a warning: (gimp-2.2:1827): Gtk-CRITICAL **: file gtktreemodel.c: line 1822 (gtk_tree_row_reference_new_proxy): assertion `GTK_IS_TREE_MODEL (model)' failed Using the entry causes more warnings: (gimp-2.2:1827): Gtk-CRITICAL **: file gtkentrycompletion.c: line 946 (gtk_entry_completion_complete): assertion `completion->priv->filter_model != NULL' failed (gimp-2.2:1827): Gtk-CRITICAL **: file gtktreemodel.c: line 1140 (gtk_tree_model_iter_n_children): assertion `GTK_IS_TREE_MODEL (tree_model)' failed I am using gtk+-2.4.14.
Ugh, it's not entirely trivial --- it's not just a matter of checking that current_folder is not NULL. The problem is that check_is_folder(path) first gets the parent folder, then does gtk_file_folder_get_info() on the path in question. If the parent folder is not readable, check_is_folder() returns FALSE. I'm changing this function to use gtk_file_system_get_folder() directly, like it was before 2004-08-25 --- there's a comment that old versions of the gnome-vfs backend didn't handle this correctly, but they do now. There is another problem in that the only way to effectively stat() a file is to first get the parent folder with gtk_file_system_get_folder(), and then call gtk_file_folder_get_info(). If the parent folder is not readable, we are never able to know the stat info for a file even though we can reach it --- think of directories with mode 111. To solve the second problem, ::get_folder() implementations probably need to: 1. Return a folder object even if the folder is not readable. 2. Try to stat() files unconditionally when ::get_info() is called for a file inside the folder. ... but in the case of (1), how do we notify upstream that the folder is not actually readable? Does it matter? If it is not readable, the file list will appear empty, which is probably not entirely wrong.
See also bug #146185.
Code is in place now in gtk-2-4 and HEAD so that the file chooser won't crash in the situation described above. It still can't visit the folders, but at least it doesn't crash now. I'll finish fixing the file system implementations tomorrow as described in comment #2.
Nice. Thanks for such a quick response and fix. :)
can this be somehow related to http://bugzilla.gnome.org/show_bug.cgi?id=158904 ? I mean the second part of the bug (crash when asking permissions on a folder that has rootpermissions)
If you do late stat() calls, then you also need to worry more about files that come and go on the fly. The early file chooser was crashing left and right when that happened.
Fixed on HEAD.
*** Bug 301176 has been marked as a duplicate of this bug. ***
*** Bug 150585 has been marked as a duplicate of this bug. ***