Delete files owned by root, without being root (opens in new tab)

(paksoy.net)

13 pointsmustpax14y ago15 comments

15 comments

15 comments · 7 top-level

NelsonMinar14y ago· 3 in thread

Maybe my brain has been twisted by too many years of using Unix, but that's exactly how it's supposed to work. "rm" is really editing the directory, not the file, so the owner of the directory is what matters. The file may not actually even be deleted; if there's a hard link to it from another directory the file will still be there in the other places. inodes are awesome.

fffggg14y ago

I agree. This should not be surprising. The ability to link a file to a directory is different from the set of permissions necessary to change the data in the file.

Here's a practical example: I can create ~/public with permissions 777 (fully permissible) and allow my friends to read and write freely in it.

They can create files with permissions 600 (only they can read/write)

I can't open up these files and read the contents, but I can remove the entire thing from my home directory.

beej7114y ago

It's not twisted; it's just that you know it. This seems like a great article for someone who doesn't yet know it.

veyron14y ago

Also let's not forget about hard links, so that even if you 'rm' the file it will still reside ...

majke14y ago· 2 in thread

Relevant `unlink` attack:

http://lcamtuf.coredump.cx/tmp_paper.txt

saurik14y ago

This attack is actually not relevant because tmpwatch (the daemon whose behavior causes the problem) runs as root and is calling unlink as root (this is explicitly noted).

In fact, /tmp generally does not have the behavior cited by this article, as it is marked with a special access flag that only lets users modify the directory entries of files they own.

http://en.m.wikipedia.org/wiki/Sticky_bit

majke14y ago

True. Thanks for clarification. Actually, I never understood why "sticky bit" is called that way, wikipedia article gives an answer:

  The sticky bit was introduced in the Fifth Edition of Unix 
  in 1974 for use with pure executable files. When set, it 
  instructed the operating system to retain the text segment
  of the program in swap space after the process exited.

wglb14y ago· 2 in thread

And this is common knowledge.

Niten14y ago

Yes, at the risk of sounding arrogant, what is this doing on the front page of HN? This isn't a security flaw and it isn't new, it's a well-understood Unix design decision.

If the aim was to educate people about Unix design principles, then it would have been useful to include references to the relevant specifications:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/un...

or at least have some meaningful discussion about the rationale for this design and its consequences. But this is just a statement of well-known fact with no context or added value, placed behind a link-bait title.

mustpaxOP14y ago

Your point is well taken. I did not mean to imply that this is bad design decision on the part of Unix. I was also trying to articulate why the current behavior makes sense by describing the mechanics of inodes. However in my experience many novice developers, especially those with limited knowledge of Unix, find this behavior quite surprising. Delving into this curiosity presents a good jumping off point for finding out more about Unix file systems (and, yes, this is all the more reason including references). The HN audience surely includes many people, such as yourself, that consider this to be completely common knowledge but the fact that at least 9 people found the article useful indicates otherwise.

saurik14y ago· 1 in thread

If you leave a locked safe in my locked house, I cannot open the safe but I can easily dispose of it. I would argue that this behavior is intuitive.

chimeracoder14y ago

Yes, I'm not sure why this is surprising, since the write bit refers to modification of the file itself, whereas the ability to create (or delete) files in a directory is related to the write permissions for the directory.

EDIT: NelsonMinar explains this better in his comment, but if you think of the inodes, not the files, this behavior makes perfect sense.

zdw14y ago

If you want to modify this behavior, ACL's or "Extended Attributes" are your friends:

http://en.wikipedia.org/wiki/Extended_file_attributes

See also the "chattr" or "xattr" commands, depending on your unix variant

makomk14y ago

This is of course intentional. As far as I can tell, though, you can't delete a non-empty subdirectory owned by root containing files that are also owned by root, even if you own the directory containing that subdirectory. In order to delete the subdirectory you need to delete the files in it, and you can't do that unless you have permission to modify that subdirectory.

gaving14y ago

Delete files in directory owned by root, without being root http://en.wikipedia.org/wiki/Sticky_bit

j / k navigate · click thread line to collapse