How was I able to remove a root owned file without sudo

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.

Jaroslav Kucera

Posted 2017-10-03T12:13:57.813

Reputation: 1 352

Is the behaviour documented anywhere? Wouldn't this lead to possible security concerns? – hjpotter92 – 2017-10-03T13:37:24.417

2From 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. – Jaroslav Kucera – 2017-10-03T13:41:59.817

6More 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 – 2017-10-03T14:26:56.623

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. – Giacomo Catenazzi – 2017-10-03T16:09:56.293

Of course it's documented. Mentioned in this FAQ from the nineties http://www.ibiblio.org/pub/historic-linux/distributions/redhat-5.1/i386/doc/FAQ/html/Linux-FAQ-6.html#ss6.12 . https://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.

– Stéphane Gourichon – 2017-10-03T16:39:53.027

1This 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 – 2017-10-03T20:07:53.177

@Kaz should you not be able to make a hard link to a file without write permissions to the file, given that that increases the reference count of the inode? – Sneftel – 2017-10-03T20:31:45.277

@Sneftel That is problematic also and can be used to perpetrate the following hack. User A and B are on a system with quotas. A has some nice (and big) files, owned by A. B likes those files. B makes a hard link to these files in a directory inaccessible to A. B enjoys files without them counting to his quota. A removes the files to make room, thereby losing his or her last accessible link (forgot to take the measure of truncating the objects to zero length first!). They continue to count toward A's quota. – Kaz – 2017-10-03T23:41:52.920

@Kaz, that requires a filesystem with a questionable quota implementation. It's not an inherent flaw in the permissions system. – Mark – 2017-10-04T00:03:02.967

@Mark any quota implementation is questionable. While the files are linked under both A and B directories, whose quota should they count against? Suppose they count against B when they are only under B's directory. A could exploit an open directory belonging to B to stash files there and evade quota. – Kaz – 2017-10-04T00:18:29.883

@Mark I think the Linux quota implementation is just simple like that: it caps how many inodes and how many blocks a user can allocate. I think that is simply counted by ownership of object. If the inode is owned by you, then it counts as an inode toward your inode count, and all its blocks against your block count, regardless of where it sits in the tree. – Kaz – 2017-10-04T00:25:16.723

How was I able to remove a root owned file without sudo

Answers