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?

Improve this question
4
  • 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 6, 2015 at 10:06
  • 2
    Funny extension: you can also rename the file, or make hard links of it.
    – peterh
    Oct 6, 2015 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 6, 2015 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, 2015 at 16:17

2 Answers 2

Reset to default
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.

Improve this answer
7
  • 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, 2015 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, 2015 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, 2015 at 15:52
  • 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 7, 2015 at 10:54
  • 1
    Immutable attribute protects a file for any changes even from root.
    – Mircea Vutcovici
    Oct 7, 2015 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.

Improve this answer
7
  • 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 6, 2015 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, 2015 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, 2015 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, 2015 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, 2016 at 0:37

You must log in to answer this question.

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