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 46475 - Users may expose files from private folders by 'Move to Trash'
Users may expose files from private folders by 'Move to Trash'
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
unspecified
Other Linux
: High normal
: 1.1.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2001-02-09 19:23 UTC by eli
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sets permissions to 0700 for trash directories on other devices (1.03 KB, patch)
2002-06-04 20:59 UTC, Damon Chaplin
none Details | Review
Attaching a patch. (3.78 KB, patch)
2002-07-09 15:03 UTC, Rohit
none Details | Review

Description eli 2001-09-10 00:59:12 UTC
Moving a file contained in a private folder on a public server to Trash places
the file in a public Trash directory.

If it's reasonable that users may expect an /h/public directory's content to be
private by setting its permissions, then this may be a significant problem.

[Filing as food for thought at John Sullivan's request.]


* REPRODUCIBLE: Always

* STEPS TO REPRODUCE:

1. Navigate to your /h/public/{username} directory in Nautilus

2. Select "New Folder", and put a file into that new folder

3. Show Properties on the folder you just created, and remove read/write/execute
permissions for everyone except for 'Owner'.

4. Open the folder.

5. Right-click on the item you placed in it, and select "Move to Trash"

* ACTUAL RESULTS: 

 The item is now visible to the world in /h/public/.Trash-{username}.



------- Additional Comments From sullivan@eazel.com 2001-02-09 15:32:30 ----

I don't know if this is worth addressing for 1.0 or even in the future, but I
assumed it was better to have Don/Pavel/etc ponder the issue than to ignore it.
Leaving for Don to assign priority.



------- Additional Comments From don@eazel.com 2001-02-16 00:16:41 ----

Not a 1.0 blocker.




------- Additional Comments From pavel@eazel.com 2001-03-16 11:30:38 ----

One thing that might be simple and get the job done is make the Trash directory
only readable and writable by the user. 

Setting the time estimate for that solution.




------- Additional Comments From snickell@stanford.edu 2001-07-23 00:40:22 ----

Taking bugs previously assigned to Pavel, assigning them to myself. Will parse
them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:59 -------
Comment 1 John Fleck 2002-01-05 04:25:11 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Dave Bordoley [Not Reading Bug Mail] 2002-05-13 07:51:48 UTC
Seems like this could be a security issue, so marking gnome2 and
1.1.x. Alex et al. is this still relevant????
Comment 3 Luis Villa 2002-05-14 18:55:12 UTC
Marking this 'high' because it is a theoretical security concern, but
can't/won't mark 2.0.0 because it is only applicable to the (as of
yet) very small group that is affected by large multi-user installations.
Comment 4 Damon Chaplin 2002-06-04 20:59:40 UTC
Created attachment 8986 [details] [review]
Sets permissions to 0700 for trash directories on other devices
Comment 5 Seth Nickell 2002-06-12 21:19:39 UTC
The patch seems fine, please commit it to gnome-2-0 branch as well as
HEAD.
Comment 6 Damon Chaplin 2002-06-13 19:26:54 UTC
patch applied to HEAD and gnome-2-0 branch.
Comment 7 Hema Seetharamaiah 2002-07-09 09:19:41 UTC
This bug needs to be reopened.

Currently only half the problem when the home dir resides on other
devices is resolved. In this case,
gnome-vfs/modules/file-method.c:do_find_directory() ignores/overrides
user specified permissions to create .Trash with 700.

In the normal case, file perms are honored and .Trash gets created
with 755 permissions. So the user's trash is readable and this is a
concern for example, on solaris, where home dirs are created 755.

Possible solution,

First, gnome-vfs/modules/file-method.c:do_find_directory() needs to be
changed to uniformly ignore user specified permissions while creating
.Trash. gnome-vfs api documentation could also be updated to reflect
this change. 

And, nautilus has to be modified to send 0000 (something unused)
instead of the current 777.

With this I guess, we can guarantee a 700 .Trash for a user.
Comment 8 Rohit 2002-07-09 15:03:42 UTC
Created attachment 9741 [details] [review]
Attaching a patch.
Comment 9 Rohit 2002-07-09 15:05:45 UTC
Attached a patch to set permissions to 0700 for .Trash directory
created in the users home directory.
Comment 10 Dave Camp 2002-07-15 18:17:52 UTC
I applied these patches.