Ubuntu

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

Reported by Martin Erik Werner on 2009-08-24
438
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Nautilus
Fix Released
Critical
glib2.0 (Ubuntu)
Medium
Kees Cook
Dapper
Undecided
Martin Erik Werner
Hardy
Medium
Martin Erik Werner
Intrepid
Medium
Martin Erik Werner
Jaunty
Medium
Martin Erik Werner
Karmic
Medium
Kees Cook

Bug Description

Binary package hint: nautilus

TEST CASE:
1. Create a symlink to a file or folder, on which you normally are able change permissions. (touch ~/testfile && ln -s ~/testfile ~/testlink)
2. Copy the symlink to anywhere using Nautilus (ctrl+c && ctrl+v)
3. Check permissions of the symlinked file or folder

Result: Symlinked file or folder permissions are changed to 777 (drwxrwxrwx user:user)
Expected behaviour: Permissions of symlinked file folder should be unchanged

NOTE: If testing different versions, nautilus needs to be restarted (including desktop), this easily done with:
killall nautilus && nautilus &disown

This bug does not allow setting permissions which your user could not do with chmod anyway, and hence is not a privilege escalation issue.

visibility: private → public

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

summary: - Permissions on user home directory set to 777 after copying it via
- nautilus
+ Permissions on user home directory (source) set to 777 after copying it
+ via nautilus

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

Martin Erik Werner (arand) wrote :

^ Confirmed behaviour on second laptop as well.

tags: added: copy home nautilus permission
Pedro Villavicencio (pedro) wrote :

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.

Changed in nautilus (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Medium
Martin Erik Werner (arand) wrote :

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

Martin Erik Werner (arand) wrote :
tags: added: apport-collected
Martin Erik Werner (arand) wrote :

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 ~

Changed in nautilus (Ubuntu):
status: New → Triaged
Changed in nautilus:
status: Unknown → New
description: updated
summary: - Permissions on user home directory (source) set to 777 after copying it
- via nautilus
+ Permission of source folder in ~ set to 777 if symlinked and copied via
+ nautilus
Martin Erik Werner (arand) wrote :

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.

summary: - Permission of source folder in ~ set to 777 if symlinked and copied via
- nautilus
+ Permission of symlinked source file/folder set to 777 if symlink is
+ copied via nautilus
description: updated
tags: added: symlink
removed: home
summary: - Permission of symlinked source file/folder set to 777 if symlink is
- copied via nautilus
+ Subscribe someone else Search Search
+ arand • Launchpad > Ubuntu > “nautilus” package Overview / Code /
+ Bugs / Blueprints / Translations / Answers Bug #418135 reported by
+ arand on 2009-08-24 (Activity log) Bug #418135: This report is public
+ edit Security vulnerability Permissions of symlinked source file/folder
+ set to 777 if symlink is copied via nautilus
description: updated
summary: - Subscribe someone else Search Search
- arand • Launchpad > Ubuntu > “nautilus” package Overview / Code /
- Bugs / Blueprints / Translations / Answers Bug #418135 reported by
- arand on 2009-08-24 (Activity log) Bug #418135: This report is public
- edit Security vulnerability Permissions of symlinked source file/folder
- set to 777 if symlink is copied via nautilus
+ Permissions of symlinked source file/folder set to 777 if symlink is
+ copied via nautilus
Martin Erik Werner (arand) wrote :

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

description: updated
Pedro Villavicencio (pedro) wrote :

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

Kees Cook (kees) on 2009-08-28
Changed in nautilus (Ubuntu):
milestone: none → karmic-alpha-6
Kees Cook (kees) wrote :

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.

Kees Cook (kees) on 2009-09-01
affects: nautilus (Ubuntu) → glib2.0 (Ubuntu)
Changed in glib2.0 (Ubuntu):
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in glib2.0 (Ubuntu):
status: In Progress → Fix Released
Martin Erik Werner (arand) wrote :

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...

Kees Cook (kees) on 2009-09-01
Changed in glib2.0 (Ubuntu Intrepid):
status: New → Confirmed
Changed in glib2.0 (Ubuntu Hardy):
status: New → Confirmed
Changed in glib2.0 (Ubuntu Jaunty):
status: New → Confirmed
Changed in glib2.0 (Ubuntu Karmic):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Kees Cook (kees)
Martin Erik Werner (arand) wrote :

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)

Martin Erik Werner (arand) wrote :
Martin Erik Werner (arand) wrote :

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.

Changed in nautilus:
status: New → Fix Released
Martin Erik Werner (arand) wrote :

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

Bispop (jonipiispa) wrote :

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.

Kees Cook (kees) wrote :

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.

Martin Erik Werner (arand) wrote :

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.

Bispop (jonipiispa) wrote :

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

Bispop (jonipiispa) wrote :

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?

Martin Erik Werner (arand) wrote :

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.

Kees Cook (kees) on 2009-09-08
Changed in glib2.0 (Ubuntu Dapper):
status: New → Confirmed
Martin Erik Werner (arand) wrote :

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.

description: updated
Martin Erik Werner (arand) wrote :

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

Martin Erik Werner (arand) wrote :

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

Martin Erik Werner (arand) wrote :

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.

Bispop (jonipiispa) wrote :

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

Martin Erik Werner (arand) wrote :

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

Changed in glib2.0 (Ubuntu Dapper):
status: Confirmed → Invalid
Kees Cook (kees) wrote :

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.

Changed in glib2.0 (Ubuntu Intrepid):
status: Confirmed → Fix Committed
Changed in glib2.0 (Ubuntu Jaunty):
status: Confirmed → Fix Committed
Changed in glib2.0 (Ubuntu Hardy):
status: Confirmed → Fix Committed
Changed in glib2.0 (Ubuntu Dapper):
assignee: nobody → arand (arand)
Changed in glib2.0 (Ubuntu Hardy):
assignee: nobody → arand (arand)
Changed in glib2.0 (Ubuntu Intrepid):
assignee: nobody → arand (arand)
Changed in glib2.0 (Ubuntu Jaunty):
assignee: nobody → arand (arand)
Changed in glib2.0 (Ubuntu Intrepid):
importance: Undecided → Medium
Changed in glib2.0 (Ubuntu Jaunty):
importance: Undecided → Medium
Changed in glib2.0 (Ubuntu Hardy):
importance: Undecided → Medium
Kees Cook (kees) wrote :

CVE-2009-3289

Launchpad Janitor (janitor) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in glib2.0 (Ubuntu Hardy):
status: Fix Committed → Fix Released
Changed in glib2.0 (Ubuntu Intrepid):
status: Fix Committed → Fix Released
Changed in glib2.0 (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Brian Shezi (brianshezi) on 2009-10-14
visibility: public → private
visibility: private → public
Brian Shezi (brianshezi) on 2009-10-31
Changed in glib2.0 (Ubuntu Dapper):
status: Invalid → Fix Committed
Steve Langasek (vorlon) on 2009-10-31
Changed in glib2.0 (Ubuntu Dapper):
status: Fix Committed → Invalid
Changed in nautilus:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.