Why is rm allowed to delete a file under ownership of a different user?

Question

From the post Why can rm remove read-only files? I understand that rm just needs write permission on directory to remove the file. But I find it hard to digest the behaviour where we can easily delete a file who owner and group different.

I tried the following

mtk : my username
abc : created a new user

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

I was thinking this shouldn't have been allowed. A user should be able to delete only files under his ownership? Can someone shed light on why this is permitted? and what is the way to avoid this? I can think only restricting the write permission of the parent directory to dis-allow surprised deletes of file.

Solution 1

The reason why this is permitted is related to what removing a file actually does. Conceptually, rm's job is to remove a name entry from a directory. The fact that the file may then become unreachable if that was the file's only name and that the inode and space occupied by the file can therefore be recovered at that point is almost incidental. The name of the system call that the rm command invokes, which is unlink, is even suggestive of this fact.

And, removing a name entry from a directory is fundamentally an operation on that directory, so that directory is the thing that you need to have permission to write.

---

The following scenario may make it feel more comfortable? Suppose there are directories:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

And there is a file which is owned by me and which has two hard links:

/home/me/myfile
/home/you/myfile

Never mind how that hard link /home/you/myfile got there in the first place. Maybe root put it there.

The idea of this example is that you should be allowed to remove the hard link /home/you/myfile. After all, it's cluttering up your directory. You should be able to control what does and doesn't exist inside /home/you. And when you do remove /home/you/myfile, notice that you haven't actually deleted the file. You've only removed one link to it.

---

Note that if the sticky bit is set on the directory containing a file (shows up as t in ls), then you do need to be the owner of the file in order to be allowed to delete it (unless you own the directory). The sticky bit is usually set on /tmp.

Solution 2

In order to unlink a file, you just need to be able to write to the directory the file is in.

If you don't like this, you could set the "sticky" bit via chmod +t dir if you are on a halfway recent OS (this feature was introduced around 1986 in SunOS).

If you like to be more fine grained, you need a filesystem with a modern ACL implementaion like ZFS. The standard NFSv4 ACLs based on NTFS include support for file specific delete permissions per user and a "delete_child" permission for directories.

Comments

[Stéphane Chazelas]

Note that to add the t bit, you need to own the directory. And if you own the directory, you can always remove files regardless of whether the t bit is set or not. If you link a file to somebody else's directory, you should be prepared for somebody else to be able to remove it. An alternative would be to first create a sub-dir of yours and add your file there instead, as the owner would not be able to remove that subdir if it's not empty.

[Overmind Jiang]

With the sticky bit on the directory, you need to be able to modify the file to be allowed to remove it. That is, if the file belongs to someone else in the same group as you, and the group may write to the file, you can remove the file. Corollary: anyone can remove a file with public write permission. (All subject to being able to modify the directory, of course.)

[Celada]

I may be misinterpreting you but aren't you saying then that I can remove -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/foo as my regular user (/tmp is sticky`) because I am allowed to write it? Yet I cannot.

[Overmind Jiang]

I'll need to reinvestigate, but yes that is what I was saying. If I can write to the file, I can destroy it anyway. Which system are you testing on?

[Celada]

That was on Linux 3.16.0-46-generic Ubuntu trusty.

[reinierpost]

You describe the situation in a misleading way. Technically, a file is not in a directory; rather, a name for a file is in the directory, and rm is an operation on the directory, not on the file. A file does get removed when the last reference to it is removed, but technically, that is a side effect.

[Scott - Слава Україні]

I believe that the me/you scenario comes into clearer focus if you hypothesize that the user (the one who doesn’t own the file) created the link.  Pronouns are hard to use; let’s say Al creates /home/al/file1, and Bob, who has execute (and maybe read) access to /home/al, hard-links the file to /home/bob/als_file.  Should Bob be prevented from removing a link that he created?  And should Al be allowed to delete (unlink) /home/bob/als_file when he doesn’t have write access to /home/bob?  This road leads to chaos.

[Overmind Jiang]

@Kevin: yes, and no. Yes, there are some major differences between unlinking a file and truncating it. No; the net result is the same — the information in the file (not about the file) is all lost. I do know there's a difference, but in terms of the information in the file after the operations, there isn't much net difference.

[Barmar]

@Kevin I think the point is that if someone has write permission to the file, so he can destroy the contents, then he might as well be allowed to unlink it as well (assuming he also has write permission to the directory). The converse doesn't apply -- being able to remove the file from one directory doesn't mean he should be able to destroy the contents, since they may be accessible from another directory. This is the logic behind how the sticky bit works.

[Scott - Слава Україні]

@Barmar: As I read Kevin's comments, and especially the one where he cited my comment, I started thinking that I should post a response.  And then I saw that you had already done so; I couldn't have said it any better.  +1