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

Architecturefileshistorypermissionsrm

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.

Best Answer

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.

Related Question