39

So I was doing some maintenance on my server earlier today and noticed I was able to delete a file owned by root in my home directory.

I was able to reproduce a sample:

[cbennett@nova ~/temp]$ ls -al
total 8
drwxrwxr-x.  2 cbennett cbennett 4096 Oct  5 20:59 .
drwxr-xr-x. 22 cbennett cbennett 4096 Oct  5 20:58 ..
-rw-rw-r--.  1 cbennett cbennett    0 Oct  5 20:58 my-own-file
[cbennett@nova ~/temp]$ sudo touch file-owned-by-root
[cbennett@nova ~/temp]$ ls -al
total 8
drwxrwxr-x.  2 cbennett cbennett 4096 Oct  5 21:00 .
drwxr-xr-x. 22 cbennett cbennett 4096 Oct  5 20:58 ..
-rw-r--r--.  1 root     root        0 Oct  5 21:00 file-owned-by-root
-rw-rw-r--.  1 cbennett cbennett    0 Oct  5 20:58 my-own-file
[cbennett@nova ~/temp]$ rm file-owned-by-root
rm: remove write-protected regular empty file ‘file-owned-by-root’? y
[cbennett@nova ~/temp]$ ls -al
total 8
drwxrwxr-x.  2 cbennett cbennett 4096 Oct  5 21:00 .
drwxr-xr-x. 22 cbennett cbennett 4096 Oct  5 20:58 ..
-rw-rw-r--.  1 cbennett cbennett    0 Oct  5 20:58 my-own-file
[cbennett@nova ~/temp]$

My question is how was I able to delete a file that's owned by root and has permissions -rw-r--r--, while I'm not root?

  • 6
    You can remove the entry in the directory that points to the file because you have write access to the directory. You can't necessarily delete the file; the file might have another hard link somewhere else. – immibis Oct 6 '15 at 10:06
  • 2
    Funny extension: you can also rename the file, or make hard links of it. – peterh Oct 6 '15 at 10:08
  • 11
    Please reconsider your choice for the accepted answer, because current one is downright misleading: you are not allowed to do anything to it ant the contents within it based on the directory's permissions. – Cthulhu Oct 6 '15 at 10:38
  • @Cthulhu Done! Thanks everyone for all the comments to this Q&A, definitely a lot of useful information here! – Carl Bennett Oct 7 '15 at 16:17
33

The permissions, content and all attributes are part of the inode. The name is in the directory entry. The permissions are not inherited recursively (except when you use default in Posix ACLs).

When you delete a file, internally you just remove a hard link from the directory entry to the inode. When all hardlinks are removed and the inode is not in use, the filesystem will reclaim the space. You need only write permission on the folder no matter which permissions are set on the file (with the exception of immutable ext permission). Same for an empty folder.

When you delete a folder that is not empty you need write permission on the folder you are deleting and its parent.

  • 1
    So the permissions are on the inode or the permissions are on the link to the inode, and I'm just removing that link (and thus the only link to it is removed, so the inode ceases to exist)? – Carl Bennett Oct 5 '15 at 23:09
  • 3
    Permissions are on the inode. This is easily verified by creating a hard link to a file, changing the permissions on that, and then checking the permissions on the original. – Wouter Verhelst Oct 6 '15 at 6:35
  • but let's say there is a directory and a file in it both belonging to root, the directory being in a directory owned by the user. You wouldn't be able to remove them then, right? – njzk2 Oct 6 '15 at 15:52
  • 1
    It is an attribute specific to ext2, ext3, and ext4. Example: sudo touch test_file;sudo chattr +i test_file;rm -f test_file See: man chattr – Mircea Vutcovici Oct 7 '15 at 10:54
  • 1
    Immutable attribute protects a file for any changes even from root. – Mircea Vutcovici Oct 7 '15 at 12:50
19

When you own the directory you are allowed to do anything to it and the contents within it based on the directory's permissions. Therefore, despite not owning the file, you were still able to delete it because you had read/write permission to the directory in which the file resided.

  • 46
    Not exactly. For example, OP wouldn't be able to modify that root-owned file. The thing is, deleting a file is not considered an operation on file but rather on directory (removing pointer to a file) and that's why permissions on the directory mattered. – Cthulhu Oct 6 '15 at 10:35
  • 1
    @Cthulhu so could you delete a root owned file, and create a new modified one with the same name after? – KDEx Oct 7 '15 at 6:21
  • 3
    @Morgoroth yes you could, but that would not be the same file anymore. For another (perhaps more obvious) example, you would not be able to read the file in your directory if it belonged to the root and only its owner could read it. – Cthulhu Oct 7 '15 at 7:14
  • @inetknght This should be clarified. I understand that you are trying to refer to manipulating the files themselves, as entities, but that's not clear. You are not able to modify its contents, for example. And you don't mention attributes which may trump directory permissions. – Mike S Oct 16 '15 at 18:15
  • 1
    @captcha That's because vi saves file first in temporary copy, then deletes the original file and renames the copy into the original (or something like that). – Cthulhu Jul 21 '16 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.