GNOME Bugzilla – Bug 322841
incorrect permissions required to delete directory
Last modified: 2021-06-18 15:50:39 UTC
This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=18670 "Description: Nautilus requires directory foo to have read and write permissions to permit deletion. Expected Results: User only requires write and execute permission (with sticky bit off) on foo's parent directory in order to delete foo (or any other file in foo's parent). Steps to reproduce: jconte@kunto:~/Desktop $ mkdir foo jconte@kunto:~/Desktop $ chmod 600 foo jconte@kunto:~/Desktop $ sudo chown root.root foo Password: jconte@kunto:~/Desktop $ ls -ld . foo drwxr-xr-x 4 jconte jconte 496 2005-10-30 10:55 . drw------- 2 root root 48 2005-10-30 10:55 foo Foo cannot be deleted from Nautilus at this point. jconte@kunto:~/Desktop $ sudo chmod 606 foo jconte@kunto:~/Desktop $ ls -ld . foo drwxr-xr-x 4 jconte jconte 496 2005-10-30 11:19 . drw----rw- 2 root root 48 2005-10-30 11:19 foo Nautilus will now enable the user to delete foo. Build and Version: Ubuntu 5.10 Breezy Badger Nautilus 2.12.1"
GnomeVFS Only exports the permsissions (and the effective access rights ala GNOME_VFS_PERM_ACCESS_*). To do The Right Thing[tm] with those information is up to the specific application. I am reassigning that to nautilus therefore.
Maybe I could suck less.
Confirmed as described on 2.14.0, but I'm not sure this is a bug. I can `rmdir foo` at a shell but not delete foo in Nautilus -- but the delete action in Nautilus is really `mv foo .Trash`, which wouldn't work in a shell. So, since we don't provide an `rmdir` in Nautilus, I think this is NOTABUG. Does that make sense?
Perhaps the user could get a dialog asking "This item cannot be moved to the trash. Would you like to delete it immediately?". I'm not sure if that is optimal but it seems better than displaying an error message and requiring the user to drop to a shell.
reopening, as suggested by the previous comment it should open a dialog asking if the user want to delete them directly
Still valid. In 2.21.6 we got the dialog asking to delete it directly, but does not work (it gives a message saying it requires read permissions to the directory to delete it).
Still valid, seems enumerator = g_file_enumerate_children (dir, G_FILE_ATTRIBUTE_STANDARD_NAME, G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, job->cancellable, &error); in nautilus-file-operations.c ~1479 is the root of the problem. But maybe should_skip_readdir_error() could help somehow...
Still here. Test case: drwxr-xr-x 3 wodny wodny 4096 Sep 1 12:39 . drwxr-xr-x 5 wodny wodny 4096 Sep 1 12:39 .. drwx------ 2 root root 4096 Sep 1 12:39 testdir Testdir is empty. Rmdir testdir will succeed. Gvfs-rm will succeed. Removing testdir through nautilus will fail. Tested with nautilus 2.30.1-0ubuntu1.2 which is old but git blame suggests not much happened with the code in libnautilus-private/nautilus-file-operations.c. I've reported a similar bug for libfm0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639982 The problem is somewhere here I suppose:
+ Trace 228454
Created attachment 222979 [details] [review] Try to remove directories even if we can't read the contents
Review of attachment 222979 [details] [review]: sorry it took so long to review. This patch doesn't work as expected since even if we try to delete it it doesn't delete it and doesn't provide any feedback. I guess we need another check somewhere. So I'm marking as needs-work
Also I expect this to be not so difficult and we have a patch from Jon, so marking as newcomer (or Jon in case you want to update it feel free!)
Created attachment 322950 [details] [review] Fix deleting writable but not readable directory I'm new. I am open to any feedback on this patch, though.
Review of attachment 322950 [details] [review]: Thanks for the patch! For now I will point some minor issues, and later I will review the code itself. The commit message is not wrapped and doesn't follow the guidelines[0], although it's well explained, so congrats for that. Also you do some unrelated changes. Do not do any style change or so, just code that changes behavior. Also seems some indentation is wrong, try to make it aligned like other parts of the code. [0]https://wiki.gnome.org/Newcomers/CodeContributionWorkflow#Commit_guidelines Also some comments inline (you can check the whole code clicking "review"). ::: libnautilus-private/nautilus-file-operations.c @@ +1658,3 @@ if (IS_IO_ERROR (error, PERMISSION_DENIED)) { + secondary = f (_("The folder “%B” cannot be deleted because you do not have " + "permissions to read it."), dir); why this change?
FYI, I was reading the commit guidelines located on the Submitting Patches page[0]. Those guidelines seem to be different from the ones you sent me. I will certainly fix the message, though. Looks like I am using tabs instead of spaces. That would explain the bad indentation. I will go ahead and fix that. Sorry. Did not mean to make style changes. I was debugging some other code and I might have left a newline or something like that. I will fix that also. Thanks for the feedback!
(In reply to Daniel Beal from comment #14) > FYI, I was reading the commit guidelines located on the Submitting Patches > page[0]. Those guidelines seem to be different from the ones you sent me. I > will certainly fix the message, though. I'm not aware on any other commit guideline page, so not sure what page I sent to you. This one linked here is the one to follow. It's good to check the patch before attaching, you can do it in for example gitg, I normally use it for this purpose and it's the one GNOME provides. About the tabs & spaces.. actually nautilus it's in a weird state, so no worries, try to follow the code around it and we can discuss it further on IRC. yw about the feedback!
Created attachment 323013 [details] [review] Fix not being able to delete writable directory that is not readable This is a bug which prevents the user from being able to delete a directory which they can write to, but not read the contents of. If the directory is empty, the folder can still be deleted even if the user cannot read it. This fix works by first having nautilus try to delete the folder even if it cannot recursively delete sub files or folders. Also, if the user attempts to move the file to trash, nautilus will inform the user that this cannot be done and offer to permanently delete the file instead. In order for this fix to be made, the trash_file function had to be modified to return the value of the to_delete GList pointer so that calling functions could keep track of the delete file list response.
Review of attachment 323013 [details] [review]: Hey, this patch slipped my emails, sorry about that. If that happens again, feel free to ping me on here. The code changed slightly, do you want to update the patch accordingly? I believe the code is going to be simpler now. I think the idea it's mostly fine, but worth double check when it's updated. ::: libnautilus-private/nautilus-file-operations.c @@ +2001,3 @@ } +static GList* We are trashing just one file. I believe with the to_delete handling we have now ins mater you will be fine.
Hi Carlos, Unfortunately it has been too long. Months ago I was considering this project as a new venture, but I then decided I would prefer elsewhere. If I were to update this patch now, I would have to reinstall and setup the environment again, and I would rather not do that. Thank you for the feedback, though. Sorry.
(In reply to Daniel Beal from comment #18) > Hi Carlos, > > Unfortunately it has been too long. Months ago I was considering this > project as a new venture, but I then decided I would prefer elsewhere. If I > were to update this patch now, I would have to reinstall and setup the > environment again, and I would rather not do that. > > Thank you for the feedback, though. Sorry. No problem, thanks for your work!
Created attachment 343917 [details] [review] Delete an empty folder with -wx- permissions. Kindly review, thanks. Atul Anand.
Review of attachment 343917 [details] [review]: Heya, I'm looking at the code and the issue is that you are not using the to_delete list, so it doesn't report the progress of deleting files and also is not reporting of any error trashing the file happens. So I think what we need is to make to_delete work in this case.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.