Non sudo user prompted with message "rm: remove write-protected regular empty file" instead of permission denied

Question

I added an extra disk to a linux server.

I added the following line to the fstab:

UUID=e277f402-bbac-4830-bc1d-5a849ffe7f9c /disk1          ext4    defaults 0 0

I then created a mount point /disk1 and mounted it

 sudo mkdir /disk1
 sudo mount /disk1

I then created an empty file touch1.txt as user "hari" and its permissions were as follows

sudo touch test1.txt

-rw-rw-r-- 1 hari hari     0 Sep 12 18:23 test1.txt

Now when I log in as another user and delete the test1.txt file it actually asks me and then denies me instead of saying "Permission denied". Why is that so? and how can I make it behave like "normal"

hari2@UBUNTU01:/disk1$ rm test2.txt
rm: remove write-protected regular empty file ‘test2.txt’? y
rm: cannot remove ‘test2.txt’: Operation not permitted

Solution

Unix permissions are a little bit odd when it comes to the remove operation.

To start with, deleting a file really involves removing the link to the file from a directory. Since most Unix filesystems allow hard links, it is possible for the file to be linked from more than one directory, so more than one link exists. And when you remove a link, the file is not deleted unless no other links to it exist.

For this reason, the actual system call used to "remove" a file is called unlink. However, the shell command utility which accomplishes the unlink is called rm, which is a mnemonic for "remove".

Since the unlink operation modifies the directory (by removing the directory entry) and not the file, the permission needed for the operation is the write permission on the directory. The permissions on the file itself are irrelevant.

However, as it turns out, it is a common mistake to try to delete a file which does not actually belong to you from a directory in which you have write permission. (More accurately, the situation is not common, but in cases where it exists, it is somewhat common to erroneously attempt to delete the file.)

To help protects sysadmins from shooting their own toes, the rm utility first verifies that the person invoking it has write permission on the file, even though that permission is not necessary to unlink the file. For obvious reasons, it does this check before attempting to delete the file.

The rm utility does not check whether the use is allowed to unlink the file, because "check before action" is generally considered bad style. Rather, it performs the desired action, and reports failure if the operating system returns an error. In this case, the OS will report EACCES because the user does not have write access to the directory.

The unfortunate consequence is that if you attempt to delete a file for which you do not have write permission from a directory in which you do not have write permission, rm will rather futilely ask you whether to proceed and then report failure.