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.

Community
  • 1
mtk
  • 27,530
  • 35
  • 94
  • 130

3 Answers3

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.

Stéphane Chazelas
  • 544,893
Celada
  • 44,132
  • 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 '15 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 01 '15 at 02:17
  • 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? – Jonathan Leffler Sep 01 '15 at 02:27
  • That was on Linux 3.16.0-46-generic Ubuntu trusty. – Celada Sep 01 '15 at 02:29
  • 1
    @JonathanLeffler: Truncating a file is an entirely different operation from unlinking it. – Kevin Sep 01 '15 at 14:38
  • 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 01 '15 at 17:38
  • 1
    @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. – Jonathan Leffler Sep 01 '15 at 18:10
  • 1
    I'm using the notation user:group:mode to designate the permissions on a file or directory. On Linux machines (RHEL with kernel 2.6.18; Ubuntu 14.04 LTS, kernel 3.13.0), and Mac OS X (10.10.5), and AIX 6, and HP-UX 11.23, user jleffler cannot remove a file /tmp/test.sticky that has someusr:somegrp:666 permissions (where jleffler does not belong to somegrp). However, on Solaris 9 (SunOS 5.9), user jleffler can indeed remove the file. So, the behaviour depends on the platform. It may also have been subject to change — Solaris 9 is not in its first flush of youth. YMMV. – Jonathan Leffler Sep 01 '15 at 18:21
  • 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 01 '15 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 02 '15 at 19:22
  • @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 – Scott - Слава Україні Sep 04 '15 at 19:06
  • According to the POSIX standard, "Whether or not files [in a directory with the sticky bit on] that are writable by the process can be removed or renamed is implementation-defined". IIRC, this feature was added by the System V folks. I always thought it was odd, but there may have been a good use case for it. – Mark Plotnick Feb 24 '16 at 17:36
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.

FUZxxl
  • 785
schily
  • 19,173
  • 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 '15 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 01 '15 at 08:57
-1

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.

rackandboneman
  • 489
  • 2
  • 5