Nemo can erase a folder containing an immutable file

[Curius16]

Distribution

Mint 21.3

Package version

6.0.2

Frequency

Always

Bug description

From Nemo, the folder containing an immutable file can be sent to the trash bin and, then, the trash bin can be emptied!

From the terminal you cannot remove the folder, even as root.
Here I make the file immutable and try to remove its containing folder which is denied as is expected:

~/folder$ mkdir test-folder

~/folder$ cd test-folder

~/folder/test-folder$ touch file

~/folder/test-folder$ ls 
file

~/folder/test-folder$ sudo chattr +i file
[sudo] Mot de passe de philippe : 
      
~/folder/test-folder$ lsattr
----i---------e------- ./file

~/folder/test-folder$ cd ..

~/folder$ rm -r test-folder
rm: impossible de supprimer 'test-folder/file': Opération non permise
rm: impossible de supprimer 'test-folder': Le dossier n'est pas vide

~/folder$ sudo rm -r test-folder
rm: impossible de supprimer 'test-folder/file': Opération non permise

Immediately after all this I went to Nemo, tried to completely erase test-folder and it was denied BUT THEN tried to move it to the trash bin and it worked!

I went to the trash bin and clicked on "Empty the trash bin" and it worked and the immutable file had been definitely erased.

Actually one can find the file erased in ~/.local/share/trash/expunged/nnnnnnnnnnn/
nnn… being a number of digits.

Either the transfer to the trash bin of a folder containing an immutable file or the emptying of the bin should be denied as is the case when one try to erase the folder from the terminal.

Steps to reproduce

1. Create a folder and in it a file.
2. Set the immutable attribute to the file (sudo chattr +i file).
3. In Nemo send the folder containing the immutable file to the trash bin.
4. Empty the trash bin.
5. The so-called « immutable » file has been deleted!

Expected behavior

Either the transfer to the trash bin of a folder containing an immutable file or the emptying of the bin should be denied as is the case when one try to erase the folder from the terminal.

Additional information

I can reproduce the abnormal behaviour of Nemo (not respecting the extended attributes of the filesystem, ext4 here) in Debian 12 Cinnamon.

[xenopeek]

To add:

• It works correctly when you Delete (move to trash) the immutable file itself; Nemo gives an error it can't do that
• And same when you Shift + Delete (permanently delete) the directory with the immutable file; Nemo gives an error it can't do that

But when you Delete (move to trash) the directory with an immutable file there is no error, it is moved to Trash without any error. And emptying Trash also gives no error — it moves the deleted immutable file to the expunged directory.

[mtwebster]

From man chattr:

A  file  with  the 'i' attribute cannot be modified: it cannot be deleted or renamed,
no link can be created to this file, most of the file's metadata can not be modified,
and the file can not be opened in write mode. Only the superuser or a process,
possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Trashing a file (using gvfs) is not deleting it, it's moving/renaming it - this seems like a lame distinction to me, but it fits here I guess. Are you able to move or rename it from a terminal with that flag set (either the file itself or its parent)?

Normally files will be truly deleted when you empty the trash. The expunged folder is for files that couldn't be permanently removed for various reasons like permissions/ownership issues:

https://askubuntu.com/questions/351400/deleting-contents-of-local-share-trash-expunged

This might not be easy to work around in nemo, especially if attempting to operate on a parent folder instead of the file directly. The 'can we trash this' check applies only to the current file selection, not its contents, and the Gio library (along with gvfs) actually performs this work.

[Curius16]

The bug is not about the immutable file but the folder containing it.

This cannot be the normal operation of the immutability feature.

What would be the use of this feature of the « immutable » file if it would be enough to send the folder to the trash and empty this one to delete the file?

For the user the fact that the file has been buried in hidden folders in the depths of the hierarchy of the filesystem changes nothing: he has lost the so-called « immutable » file that was presumably protected!

To be assured that the file cannot be lost, whatever you may do to the file or the folder containing it or anything else, is the very justification of the existence of this attribute: there cannot be any other at all.

[mtwebster]

Open a bug here: https://gitlab.gnome.org/GNOME/gvfs/

Every file manager I tried behaves this same way, because they rely on gvfs to handle trash.