Sticky bit and chattr

Question

I want to protect my folders in $HOME from an accidental deletion. I applied chattr +i on them but i noticed that the last is applied recursively, thus, indeed the folder can't be deleted but also i can't write in it.

I also tried to apply a sticky bit with chmod 1775 and change the ownership of the folder with chown root foldername. Normally, with sticky bit enabled, only the owner of the folder can delete it but, strangely, in my case although the folder is owned by root, i can delete it with my normal user.

I noticed that the users folders in /home partition, although they are owned by the current user and have rwx permissions for the owner, they can't be deleted/changed. How is this achieved?

I am using Arch Linux 32-bit and the filesystem is ext4.

Answer 1

I want to protect my folders in $HOME from an accidental deletion. I applied chattr +i on them but i noticed that the last is applied recursively, thus, indeed the folder can't be deleted but also i can't write in it.

It's not recursive, it's just how directories work. A directory is basically a special file with a list of names and inodes. (At least it used to be; you still can cat directories on some BSDs.) When you try to create, rename or delete a file, you're not changing the file itself, you are changing its parent directory. If the directory is marked as immutable, you can't change it – but subdirectories can still be modified.

I also tried to apply a sticky bit with chmod 1775 and change the ownership of the folder with chown root foldername. Normally, with sticky bit enabled, only the owner of the folder can delete it but, strangely, in my case although the folder is owned by root, i can delete it with my normal user.

The sticky bit allows deleting objects if you own either the object itself or its parent directory.

I noticed that the users folders in /home partition, although they are owned by the current user and have rwx permissions for the owner, they can't be deleted/changed. How is this achieved?

See above – when deleting a filesystem object, you must have 'write' permission on the parent directory, not on the object itself. In this case, /home is owned by root, and you only have "read"+"execute" permissions.

In conclusion,

backups.

---

filesystem object: n. a file, directory, device node, symlink, pipe, Unix socket, or whatever the hell else can be stored on the filesystem.

Answer 2

To create, remove, or rename an item in a directory you must have write permission to the directory. Usually /home is not writable to ordinary users so you cannot create, remove, or rename a directory under /home.

The sticky bit on a directory adds an additional requirement that only the file or directory owner (or the superuser) can remove or rename existing items within the directory. It won't prevent you from deleting things that you own. It is intended for public directories like /tmp, in order to allow anyone to create new files, and to remove or rename files that they own, but to prevent removal or renaming of files owned by other users.

Making a directory immutable (chattr +i) means that it cannot be changed at all, so no new files can be created in it, and nothing in it can be removed or renamed. If you want to prevent a directory from being deleted but still want to be able to create, remove, and rename files within it, you could do that by creating an immutable file within the directory, since a directory cannot be removed as long as there is something in it. Alternatively you could create a subdirectory with no write permission that contains at least one file.