53

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.

Improve this question
0

3 Answers 3

Reset to default
104

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.

Improve this answer
12
  • 6
    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.)
    – Jonathan Leffler
    Aug 31, 2015 at 14:01
  • 1
    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.
    – Celada
    Sep 1, 2015 at 2:17
  • 4
    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.
    – Scott - Слава Україні
    Sep 1, 2015 at 17:38
  • 2
    @JonathanLeffler: As Scott's example shows, no, unlinking and truncating do not have the same net result when there are hard links in play.
    – Kevin
    Sep 1, 2015 at 21:12
  • 6
    @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.
    – Barmar
    Sep 2, 2015 at 19:22
9

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.

Improve this answer
2
  • 9
    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.
    – Stéphane Chazelas
    Aug 31, 2015 at 11:07
  • 6
    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.
    – reinierpost
    Sep 1, 2015 at 8:57
0

The logic is similar to that of a house: The owner or tenant decides which guests to throw out, no matter who owns the guests. Also, the evicted guest that is welcome in another house (has another hardlink in someone else's directory) will not freeze to death outside.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .