48

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?

Stefan Lasiewski
  • 23,667
  • 41
  • 132
  • 186
Carl Bennett
  • 783
  • 3
  • 7
  • 14
  • 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. – user253751 Oct 06 '15 at 10:06
  • 2
    Funny extension: you can also rename the file, or make hard links of it. – peterh Oct 06 '15 at 10:08
  • 12
    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 06 '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 07 '15 at 16:17

2 Answers2

39

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.

Mircea Vutcovici
  • 17,619
  • 4
  • 56
  • 83
  • 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 05 '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 06 '15 at 06: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 06 '15 at 15:52
  • If you run `sudo mkdir d;sudo touch d/f;chmod 777 d/f` then `rm -rf d;rm -f d/f` will fail because the `f` file can not be deleted from `d` folder because user has no access to `d` folder owned by root. But you will be able to run: `echo hello> d/f` because any user has permission to change the file. – Mircea Vutcovici Oct 06 '15 at 17:01
  • What do you mean by "immutable ext permission"? – Peter Mortensen Oct 07 '15 at 08:31
  • 2
    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 07 '15 at 10:54
  • 1
    Immutable attribute protects a file for any changes even from root. – Mircea Vutcovici Oct 07 '15 at 12:50
21

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.

inetknght
  • 391
  • 3
  • 6
  • 51
    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 06 '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 07 '15 at 06: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 07 '15 at 07: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
  • @Cthulhu I just created a root-owned file with 644 permissions in my user folder and WAS able to modify and save its contents back to disk. vi alerted read-only but with :wq! I was able to override that warning and save it. – captcha Jul 20 '16 at 23:29
  • 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 00:37
  • @Cthulhu ah, that makes sense. I just tried with a simple echo "blah" >> testfile and this failed with a 'Permission denied' error. So vi must also restore the file's owner and existing permissions. Interesting.. – captcha Jul 21 '16 at 00:57