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 40990 - Nautilus permission check thinks operations are not allowed, when they really are
Nautilus permission check thinks operations are not allowed, when they really...
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.10.x
Other Linux
: Normal minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 165791 301982 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2000-05-25 21:08 UTC by Maciej Stachowiak
Modified: 2010-01-23 18:49 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Maciej Stachowiak 2001-09-10 00:34:11 UTC
Here are some cases where this may be true. Using access() through an
appropriate gnome-vfs cover may or may not help some of these cases. This list
is similar to the list in bug #40989

* AFS uses ACLs (Access Control Lists) to represent file permissions. Although
it reports user-group-other permissions, they are essentially ignored. So trying
to use these permissions will result in completely incorrect results.

* Native filesystems on un*x systems that support ACLs (for example, Solaris and
other proprietary unixen; and similar functionality is under development for
Linux) because then the real check the kernel uses is the ACLs, not the checks
described above.

* On some systems that have "capabilities" support, a user other than uid 0 may
have permission to real all files via a "capability".

* NFS servers may do even more complex UID mappings than that - the client UID
may be mapped to a completely different UID on the server. The access(2) man
page implies that even access() will not return correct results for this case! I
don't really know much about the specifics of this problem though.

* When mounting windows file shares (SMB) on a Linux system, Unix
user/group/owner permissions are approximated, but the server actually uses a
different check, so again looking at the permissions may give incorrect results.

* The permissions of the file may change between when we do the test and when we
do the operation.

* For gnome-vfs file systems like http or ftp, our permissions are not tied to
our unix UID or group at all, but rather to some different model of permissions;
for ftp this could be the user we are logged into the ftp site as, for http it
could be based on an htaccess file on the server (which is essentially a model
like ACLs).



------- Additional Comments From darin@bentspoon.com 2000-05-25 17:13:26 ----

This is a more important problem than the one in bug 40989 because it means you
actually can't do things with the file manager that you can with the shell.



------- Additional Comments From darin@bentspoon.com 2000-05-25 17:14:41 ----

Once we figure out the specific cases, we may want separate bug reports.



------- Additional Comments From eli@eazel.com 2000-10-16 20:17:58 ----

Batch-assigning QA ownership of remaining bugs to eli@eazel.com



------- Additional Comments From snickell@stanford.edu 2001-07-23 00:36:16 ----

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:34 -------
Comment 1 John Fleck 2002-01-05 04:07:11 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Luis Villa 2002-10-31 13:27:19 UTC
As per the comments on the other bug.
Comment 3 Stephane Wirtel 2005-01-26 22:06:02 UTC
No news for this bug, 

I close it
Comment 4 Sebastien Bacher 2005-02-01 10:28:18 UTC
*** Bug 165791 has been marked as a duplicate of this bug. ***
Comment 5 Michael Pasdziernik 2005-02-05 10:50:52 UTC
This bug needs higher severity and priority. 
It makes nautilus useless in professional environments.
Why is it five years old?
Comment 6 Olav Vitters 2005-04-25 22:22:43 UTC
*** Bug 301982 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Kasak 2005-12-20 03:55:55 UTC
I just found this bug while searching for duplicates. I have a specific case for you.

I have a samba share mounted via cifs. The directory looks like this:

drwxrwxrwx  5 nobody nobody 0 Dec 20 14:48 ManchesterUnity

I go into the directory, select some files, and archive them with gnome's archiving tool ... it creates a tar.gz file in the ManchesterUnity folder.

I then decide I don't want the archive, so I right-click and 'move to trash', but nautilus tells me that I can't because of the permissions of the parent folder. I then use a terminal to cd into the folder and 'rm' the file with no problems.

I agree strongly with the above comment that this makes nautilus unusable. This issue came up when one of my workmates ( who I just moved to a Linux desktop ) did the above sequence.

Can someone please change the severity of this bug from minor ( ! ) to absolutely, 100% certified, you-bet-your-life-buddy critical? This is a file manager. First and foremost, it needs to be able to manage files.
Comment 8 Daniel Kasak 2006-02-07 03:02:45 UTC
.
Comment 9 André Klapper 2008-07-16 16:46:00 UTC
Is this still an issue on 2.22?
Comment 10 Harald Glatt (hachre) 2009-12-27 19:15:02 UTC
Ubuntu 9.10 - Nautilus 2.28.1:
This issue is not reproducible.

This can be closed.
Comment 11 André Klapper 2010-01-23 18:49:41 UTC
Thanks.