Permissions of symlinked source file/folder set to 777 if symlink is copied via nautilus

Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: nautilus 1:2.26.2-0ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-15-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: nautilus 1:2.26.2-0ubuntu2
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-15-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

^ Confirmed behaviour on second laptop as well.

Thanks for the report, the bug is one that needs to be send directly upstream to: http://bugzilla.gnome.org , forwarding instructions are available at: http://wiki.ubuntu.com/Bugs/Upstream/GNOME , Thanks in advance.

Confirmed in Karmic on 'first' laptop (mentioned above).

Apparently 777 permissions are also set on the subfolders: Desktop, Music, Pictures and Videos (in this specific case?)

Architecture: amd64
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: nautilus 1:2.27.91-0ubuntu1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-7.27-generic
Uname: Linux 2.6.31-7-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

This seems to be dependend on symlinks. On a new user this does not occur. However, if I create a symlink in the user directory pointing to /home/user the issue appears.

This wast most likely the cause for the earlier occurances also, since wine creates symlinks in ~/.wine/drive_c/windows/profiles/user/ to /home/user as wells as to Desktop, Music, Pictures and Videos in ~

I've sent this upstream at: http://bugzilla.gnome.org/show_bug.cgi?id=593406

Cheers Pedro, I'm in the works of hopefully narrowing the bug down a bit, so some updating in the upstream description might be required when done.

Even further testing done:
Only thing needed to reproduce is a symlink to a directory your user are able to change permissions of.
If this symlink is copied by nautilus, to anywhere, the symlinked directory will get it's permissions set to 777.

Pedro, could you update the upstream report description to match this one please?

the description cannot be updated without posting a new comment, saw you subscribed there, could you add a comment? Thanks.

This can cause really nasty side-effects for people using symlinks into their encrypted Private directory. This needs to be fixed for Karmic and SRU'd to Jaunty.

This bug was fixed in the package glib2.0 - 2.21.5-0ubuntu2

---------------
glib2.0 (2.21.5-0ubuntu2) karmic; urgency=low

  * Add debian/patches/61_skip-perms-on-symlinks.patch, fix permissions
    being overwritten when copying symlinks (LP: #418135).

 -- Kees Cook <email address hidden> Mon, 31 Aug 2009 18:49:12 -0700

This bug is also present (in virtualbox instances) on:
ubuntu 8.04 livecd & updated install
ubuntu 8.10 livecd & updated install
(fedora 11 updated install, GNOME Developer Kit 2.27.20090727 & updated)

There seems to be some SRUing to do...

Tested on Jaunty by simply adding 61_skip-perms-on-symlinks.patch from karmic source and inserting entry in series file (debian/patches).
This fixes the bug on current Jaunty.
I've created a _rough_ debdiff with my changes and added this package to my ppa: https://launchpad.net/~arand/+archive/ppa (currently building; if anyone are eager/daring to test)

This bug has been fixed upstream using what seems like a completely different method, we might have to consider whether we want that or current karmic solution.

Created a debdiff for Jaunty using the upstream patch, also added (replaced) to PPA

Hello, i noticed that if you install the updatet glib you cannot drag shortcuts onto the desktop from the applications menu anymore, it complainis about not being able to set permissions on symlinks, downgrading fixes this.

Thanks for the report! I actually just updated the patch to use the upstream patch, which should solve this regression. Once it builds, please test 2.21.5-0ubuntu3 to validate it has been fixed.

Quick testing in VBox confirms that 2.21.5-0ubuntu3 fixes the bug and solves the regression.

I mixed together a proposition debdiff for the backport to Jaunty, if that's of any use.

2.21.5-0ubuntu3 seems to fix everything, thank you.

ill take the last one back, can anyone confirm that the update crashes nautilus when trying to open the trash when it contains a *.desktop file?

Bispop, I cannot confirm that, for me viewing trash when it contains a
*.desktop file works absolutely fine. So it seems like there might be
more to that issue than just this update?

I've uploaded the proposed jaunty updated version to my ppa: https://launchpad.net/~arand/+archive/ppa

I've tested this on i386 & amd64, where I it seems to solve the issue, with no noticable regressions so far, Bispop's issue included.

I've put together a proposed update for intrepid as well which has been built and tested locally in an i386 virtualbox instance (issue gone, no immediate regressions).
This also uploaded to my ppa, testing welcome.
Attached debdiff of this proposed update.

added new debdiff for intrepid, typo in changelog regarding patch filename. (61_* is already in intrepid for another patch, I simply used 62_* instead)

Getting the fix into hardy may be non-trivial, since the patch seems to depend on the function g_set_error_literal, which is, i assume, not implemented in pre-intrepid glib (attached build errors for hardy).

This function is implemented here:
http://mail.gnome.org/archives/svn-commits-list/2008-June/msg03425.html

I've edited the patch to use g_set_error instead of g_set_error_literal (simply replacing the function since the arguments seems to already be in the right format).
Since I have minimal knowledge about the actual code involved in this I can only confirm that it works with no immediate regressions on an i386 virtualbox instance.

Yet another debdiff attached, and testing packages available in my ppa.

Arands update seems to fix everything for me now, thanks.

I just tested this on a VBox Dapper, seems like the issue is nonexistant there.
Invalidating for now.

These are building in the security queue now; thanks for all the work in testing and building! I adjusted the changelogs to use the -security pocket, but other than that, it looks great. Once they're built, I'll get them tested again and published.

CVE-2009-3289

This bug was fixed in the package glib2.0 - 2.20.1-0ubuntu2.1

---------------
glib2.0 (2.20.1-0ubuntu2.1) jaunty-security; urgency=low

  * Backported patch from Karmic: fix permissions being overwritten when
    copying symlinks (LP: #418135).
    - Add debian/patches/61_skip-perms-on-symlinks.patch (originally upstream
      commits).

 -- Arand Nash <email address hidden> Fri, 04 Sep 2009 00:55:25 +0200

This bug was fixed in the package glib2.0 - 2.18.2-0ubuntu2.2

---------------
glib2.0 (2.18.2-0ubuntu2.2) intrepid-security; urgency=low

  * Backported patch from Karmic: fix permissions being overwritten when
    copying symlinks (LP: #418135).
    - Add debian/patches/62_skip-perms-on-symlinks.patch (originally upstream
      commits).

 -- Arand Nash <email address hidden> Wed, 09 Sep 2009 12:00:45 +0200

This bug was fixed in the package glib2.0 - 2.16.6-0ubuntu1.2

---------------
glib2.0 (2.16.6-0ubuntu1.2) hardy-security; urgency=low

  * Backported patch from Karmic: fix permissions being overwritten when
    copying symlinks (LP: #418135).
    - Add debian/patches/61_skip-perms-on-symlinks.patch (originally upstream
      commits)
    - Edit patch to use g_set_error, instead of g_set_error_literal which
      is not implemented in this version of glib.

 -- Arand Nash <email address hidden> Wed, 09 Sep 2009 16:51:27 +0200