Timeline for root cannot write to file that is owned by regular user
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2024 at 18:35 | comment | added | Martin von Wittich | This is something where I would've really appreciated if the kernel developers had added a warning to dmesg whenever it happens. It's really hard to figure out what's going wrong when the kernel suddenly doesn't do what you'd expect, and until I realized that the file I was trying to overwrite was in a folder with the sticky bit set, also practically impossible to google :| | |
| Feb 21, 2022 at 22:01 | history | edited | A.B | CC BY-SA 4.0 | No gain to rewrite what's quoted: each word in the quote has an importance, telling it again differently makes it likely wrong |
| Feb 21, 2022 at 21:55 | comment | added | A.B | @JohnBollinger I made a correction, but yes even then it's difficult to parse. The text in quotes should be read "unless the owner [of the file] is the same as that of the directory". If user1 creates a a+wt directory, if the file foo with mode 666 within has for owner user1, then any user can write to it. If it has an other owner than user1, eg user2, then only user2 can write to it. In particular not user1 nor root (nor user3). | |
| Feb 21, 2022 at 21:31 | history | edited | A.B | CC BY-SA 4.0 | reword the explanation after the quote which was a bit off. |
| Feb 21, 2022 at 21:18 | comment | added | John Bollinger | "This affects only files in a directory not already owned by the user attempting to write" -- I think you're misinterpreting the feature description here, or else this answer does not explain the observed behavior. root owns /tmp (or should do), yet it is prevented from opening some files within. What the description seems actually to say in this area is that the protection does not apply if the owner of the target file is the same as the owner of the directory in which it resides or if the file is owned by the user opening it (among other exceptions). | |
| Feb 21, 2022 at 19:40 | comment | added | marcelm | @Joshua Fair enough, it appears it was turned off by default initially. It does seem this was enabled in Ubuntu starting in 20.04, almost two years ago. More conservative distributions may be slower to enable this by default, but with ~2 years exposure in a popular distribution, I still think the fallout of this change isn't all that dramatic. | |
| Feb 21, 2022 at 17:13 | comment | added | A.B | @400theCat If an user can guess the file name in advance, it can preseed it with data that an other account (root) thought it would have written on its own. If this data participates in any way to authentication... last CVE in the list (cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7489) has an example: vapidlabs.com/advisory.php?v=173 . It's a feature to prevent a category of bugs in applications. Of course the application should be fixed but... | |
| Feb 21, 2022 at 17:10 | comment | added | Joshua | @marcelm: I just checked my system and my distro has it turned off. I think we're not having many problems because it's still mostly unused. | |
| Feb 21, 2022 at 17:09 | comment | added | Martin Vegter | @A.B - thank you, but I don't understand how this increases security. After all, you have to be root to actually be affected by this. So it's not like a security feature preventing regular users to become root. | |
| Feb 21, 2022 at 12:02 | history | edited | A.B | CC BY-SA 4.0 | removed the tcpdump example, which doesn't fail because of this feature in the end on my system, but because of AppArmor. and reworded some |
| Feb 21, 2022 at 11:57 | history | edited | A.B | CC BY-SA 4.0 | removed the tcpdump example, which doesn't fail because of this feature in the end on my system, but because of AppArmor. |
| Feb 21, 2022 at 11:18 | comment | added | A.B | @trlkly this feature is especially intended to affect the root user: the target of a privilege escalation. | |
| Feb 21, 2022 at 10:28 | comment | added | marcelm | @Joshua Kernel 4.19 has been out for over 3 years, and the world hasn't ended. I think we'll survive this change. | |
| Feb 21, 2022 at 10:10 | comment | added | trlkly | I'm surprised this rule treats root the same as everyone else. | |
| Feb 21, 2022 at 4:01 | comment | added | Joshua | This one is going to make a mess. There's going to be bugs back and forth forever. | |
| Feb 20, 2022 at 18:10 | history | edited | A.B | CC BY-SA 4.0 | be more precise on the reason why truncate does fail and rm doesn't fail: it's about using open without O_CREAT. |
| Feb 20, 2022 at 17:37 | history | edited | terdon♦ | CC BY-SA 4.0 | The OP ws also wondering why root could delete the file which was the only actually useful bit of info in my now deleted answer. |
| Feb 20, 2022 at 17:18 | vote | accept | Martin Vegter | ||
| Feb 20, 2022 at 16:55 | history | edited | A.B | CC BY-SA 4.0 | doesn't affect only root |
| Feb 20, 2022 at 16:47 | history | answered | A.B | CC BY-SA 4.0 |