7

I had the following output for ls -lFh:

-rw-r--r-- 1 hjpotter92 hjpotter92  926 Aug  2 18:40 static.yaml
drwxr-xr-x 5 hjpotter92 hjpotter92 4.0K Sep 12 19:40 templates/
-rw-r--r-- 1 root       root       1.5K Sep 12 20:09 xyz

I am logged in as hjpotter92. My user does not have a NOPASSWD entry in sudoers list. Can someone explain the behaviour when I tried the following:

$ which rm
rm: aliased to rm -i
$ rm xyz
rm: remove write-protected regular file 'xyz'? y
$ sudo rm xyz
rm: cannot remove 'xyz': No such file or directory
$ ls -lFh
total 176K
<a lot of other files>
-rw-r--r-- 1 hjpotter92 hjpotter92  926 Aug  2 18:40 static.yaml
drwxr-xr-x 5 hjpotter92 hjpotter92 4.0K Sep 12 19:40 templates/
1
  • 1
    Could you include the ls -lFh output for the parent directory please
    – jrtapsell
    Oct 3, 2017 at 12:20

1 Answer 1

15

In this case there are important write permissions on the directory, where the file was. So if you can write the directory, you can also remove files there.

11
  • 2
    From security perspective it's OK. When you don't have write access to file, you can't modify it. However if the file is in the directory where you can write, you may modify the content of the directory. And the content of the directory consist of files or subdirectories. Oct 3, 2017 at 13:41
  • 6
    More generally, a single file can exist in multiple directories (via hard links). Removing the file from a directory does not necessarily erase its contents from disk.
    – Max
    Oct 3, 2017 at 14:26
  • 2
    @hjpotter92: It is well written in many documentation. There is the sticky bit to forbid deleting file that are not yours. In general, processes with privileges should have control of the directories (entire path) they write in. Oct 3, 2017 at 16:09
  • 5
    Of course it's documented. Mentioned in this FAQ from the nineties ibiblio.org/pub/historic-linux/distributions/redhat-5.1/i386/… . en.wikipedia.org/wiki/File_system_permissions#Permissions says : "The write permission grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files." The file owner does not matter. Oct 3, 2017 at 16:39
  • 1
    This is kind of a flaw in the Unix model. Removing the file does in fact constitute a modification to the file, not only the directory. The reference count of the inode decreases by one. Moreover, if that refcount hits zero, the file becomes garbage and its storage is recycled. Both of these are destructive manipulations of an object you don't own and to which you don't have write permission.
    – Kaz
    Oct 3, 2017 at 20:07

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