GNOME Bugzilla – Bug 593406
Permissions on user home directory (source) set to 777 after copying it via nautilus
Last modified: 2010-03-07 12:22:29 UTC
this report has been opened here: https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/418135 "TEST CASE: 1. Launch nautilus 2. Copy user directory to other location (e.g. /tmp) 3. Skip "special files" which cannot be copied (nautilus pop-up dialogues) 4. Check permissions of user's folder Result: user directory permissions is changed to 777 (drwxrwxrwx user:user) Expected behaviour: user directory permissions should be unchanged (755, drwxr-xr-x user:user) (To revert, simply use "chmod 755 ~") Another side-effect of this is that on startup, gnome(?) gives an error about the .drmc file and permissions (although it does only complain at that file not being 644 [which it IS]) "
Further testing and narrowing down done: 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 This does not allow setting permissions which your user could not do with chmod anyway, and hence is not a privilege escalation issue.
This applies to versions: 2.26.2-0ubuntu2 (current in ubuntu 9.04, i386 & amd64 tested) and 2.27.91-0ubuntu1 (current in ubuntu 9.10 development, amd64 tested)
Created attachment 142195 [details] [review] Do not attempt to copy file permissions into symlink targets This patch fixes the problem. It will be shipping in Ubuntu Karmic.
This bug is also present (in virtualbox instances) on: ubuntu 8.04 ubuntu 8.10 fedora 11 GNOME Developer Kit 2.27.20090727
Created attachment 142220 [details] [review] Bug 593406 - Permissions set to 777 after copying via Nautilus When doing a g_file_copy() with nofollow-symlinks (to copy a link for example), the later copying of the file attributes copies the source links 777 attributes to the target's attributes. As chmod affects the symlink target, this would cause such copies to always set the target to 777 mode. This patch makes setting the mode with nofollow-symlinks fail with NOT_SUPPORTED. The aforementioned g_file_copy() will still succeed, because it ignores errors of the attribute copy.
pushed the fix to git after getting an ok from Alex.
This breaks gio/tests/live-g-file: danw@desktop:tests (master)> ./live-g-file /live-g-file/prep_clean_structure: Cleaning target testing structure in 'testdir_live-g-file'... deleting 'dir1' deleting 'subdir' deleting 'dir2' deleting 'dir-target' deleting 'dir_no-access' OK /live-g-file/create_structure: Going to create testing structure in 'testdir_live-g-file'... Creating directory 'dir1'... Creating directory 'dir1/subdir'... Creating directory 'dir2'... Creating directory 'dir-target'... Creating directory 'dir_no-access'... ** ERROR:live-g-file.c:240:test_create_structure: assertion failed (res == TRUE): (0 == 1) Aborted
commit 48e0af0157f52ac12b904bd92540432a18b139c7 Author: Benjamin Otte <otte@gnome.org> 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. It fixes the testsuite for me at least.
*** Bug 563511 has been marked as a duplicate of this bug. ***