After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 301176 - Applications using gtk+ file dialog crash when parent directory has limited access
Applications using gtk+ file dialog crash when parent directory has limited a...
Status: RESOLVED DUPLICATE of bug 162617
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.4.x
Other All
: High critical
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-04-19 11:31 UTC by jansen
Modified: 2005-04-28 19:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8



Description jansen 2005-04-19 11:31:23 UTC
Distribution: Fedora Core release 3 (Heidelberg)
Package: gtk+
Severity: normal
Version: GNOME2.8.0 unspecified
Gnome-Distributor: Red Hat, Inc
Synopsis: Applications using gtk+ file dialog crash when parent directory has limited access 
Bugzilla-Product: gtk+
Bugzilla-Component: GtkFileSel
Bugzilla-Version: unspecified
Description:
Description of Problem:
On a couple of systems I manage, / and /home are executable for all, but
not readable. So users can access directories the know exist, but are
unable to browse these directories.
Under Fedora Core 3 this is causing a problem for applications which use
the Gtk+ file dialog, unless running under Gnome.

Steps to reproduce the problem:
1. log in using any desktop or window manager except Gnome (e.g. KDE,
XFCE, fvwm2 etc)
2. open an application which uses the gtk+ file dialog, e.g. gedit or
Fedora's version of firefox
3. open a file dialog (open file, save as, etc)

Actual Results:
*** glibc detected *** double free or corruption (fasttop): 0x08909128
*** 
the application hangs, and needs to be killed as far as I can tell

Expected Results:
A file dialog box.

How often does this happen?
Always, under those circumstances

Additional Information:
As mentioned above, all is fine under Gnome. And all is fine when / and
/home are readable to the user. It must be a strange combination of
desktop environment and file permissions which is not handled
correctly.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2005-04-19 07:31 -------


Unknown platform unknown. Setting to default platform "Other".
Unknown milestone "unknown" in product "gtk+".
   Setting to default milestone for this product, '---'
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here, unknown@bugzilla.gnome.org.
   Previous reporter was jansen@strw.leidenuniv.nl.
Setting to default status "UNCONFIRMED".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Morten Welinder 2005-04-28 13:57:51 UTC
I don't see the crash, but then again my / is readable.  I did the following:

 6756  mkdir xxx
 6757  cd xxx
 6758  mkdir yyy
 6759  cd yyy/
 6760  ln ../../gnumeric .
 6761  ls -l
 6762  chmod 0 ../../xxx
 6763  ./gnumeric 

and my file chooser comes up in the root directory.
Comment 2 Federico Mena Quintero 2005-04-28 19:43:09 UTC
This is a duplicate.  GNOME 2.8 uses GTK+ 2.4.x, which doesn't have these fixes.

Please feel free to peruse the patches in these SRPMS; they have the fix for
this bug in them as well as other numerous issues:

http://primates.ximian.com/~federico/misc/gtk+/SRPMS/

(Those packages are for Novell Linux Desktop 9, but the patches should be useful
for pretty much anything that uses GTK+ 2.4.x).

*** This bug has been marked as a duplicate of 162617 ***