Bug 524829 (CVE-2009-3289) - CVE-2009-3289 glib2: folder | symlink permissions change after copy via nautilus
Summary: CVE-2009-3289 glib2: folder | symlink permissions change after copy via nautilus
Alias: CVE-2009-3289
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: https://bugzilla.gnome.org/show_bug.c...
Depends On: 522351 538223
TreeView+ depends on / blocked
Reported: 2009-09-22 12:17 UTC by Jan Lieskovsky
Modified: 2021-11-12 20:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-17 22:28:42 UTC

Attachments (Terms of Use)

Description Jan Lieskovsky 2009-09-22 12:17:21 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-3289 to
the following vulnerability:

The g_file_copy function in glib 2.0 sets the permissions of a target
file to the permissions of a symbolic link (777), which allows
user-assisted local users to modify files of other users, as
demonstrated by using Nautilus to modify the permissions of the user
home directory.


Comment 1 Jan Lieskovsky 2009-09-22 12:19:46 UTC
This issue does NOT affect the versions of the glib2 package, as shipped
with Red Hat Enterprise Linux 3, 4, or 5.

This issue affects the versions of glib2 package, as shipped with Fedora
10 and 11.

Please fix.

Comment 3 Paul Howarth 2009-09-22 12:46:35 UTC
I think you mean glib2, not glib.

Comment 5 Vincent Danen 2011-06-17 22:28:42 UTC
Trying in Fedora 14, this seems to be corrected.  If you copy your own home folder (with 0700 perms) to /tmp, when the copy is complete, it has 0700 perms again.  During the copy it has 0775 perms, but changes when the copying is done.  I believe this issue has been corrected upstream:

commit 48e0af0157f52ac12b904bd92540432a18b139c7
Author: Benjamin Otte <otte>
Date:   Tue Sep 1 21:26:08 2009 +0200

    Bug 593406 - Permissions set to 777 after copying via Nautilus

    Only fail to set the permissions when the actual file is a symlink.
    The previous fix failed for every file when NOFOLLOW_SYMLINKS was set.

Test on RHEL6 as well and the destination file/directory will have the same permissions as the source.

Note You need to log in before you can comment on or make changes to this bug.