M
Michael Orlitzky
michael.orlitzky.com · Personal blog · on HN since 2017
Michael Orlitzky, a Gentoo developer, writes opinionated essays on Unix security, package management, TLS certificates, and language design.
What HN saysCommenters link it in discussions of POSIX hardlink and symlink security problems, noting the real issue is root accessing user-controlled files.
21HN people shared it
8linked it in comments
16stories submitted
370story points
6 months agolast shared
2017people per year2026
Most-shared posts
- 1Motherfuckers need package management (2015)6 people · 11 points · first shared 2017 · 1 comments on HN
- 2Let's Not Encrypt (2019)4 people · 119 points · first shared 2022 · 259 comments on HN
- 3Posix hardlink heartache4 people · 103 points · first shared 2021 · 47 comments on HN
- 4Greybeard's tomb: the lost treasure of language design (2019)3 people · 27 points · first shared 2021 · 2 comments on HN
- 5In defense of self-signed certificates (2013)3 people · 11 points · first shared 2020 · 1 comments on HN
- 6CSC ServiceWorks laundry machine coin bypass (2023)2 people · 73 points · first shared 2023 · 61 comments on HN
- 7Greybeard's tomb: the lost treasure of language design (2019)1 people · 26 points · first shared 2024 · 9 comments on HN
- 8Cve 2017 18188.xhtml1 people · first shared 2021
What HN people wrote when they linked it
tadfisher · 2023-10-13
Researching this, found [1]:
> POSIX guarantees that hard links can exist. It follows that, on POSIX systems without any non-standard protections, it's unsafe for anyone (but in particular, root) to do anything sensitive in a directory that is writable by another user. Cross-platform programs designed to do so are simply flawed.
I feel like something had to have been lost in translation from Unix to POSIX here. In the original implementation, were users able to hardlink (well, "link") files owned by others? If so, this is a foundational flaw that should probably be fixed across the board with something similar to Linux's non-standard sysctl option.
[1]: http://michael.orlitzky.com/articles/posix_hardlink_heartache.xhtml
yyyk2 · 2022-07-22
No, there is absolutely nothing broken about symbolic links. What is the issue here is accessing user files as root. That is inherently unsafe in POSIX and also affects hardlinks as well (even more so, since you have to "follow" hardlinks http://michael.orlitzky.com/articles/posix_hardlink_heartache.xhtml).
Joker_vD · 2026-04-29
> The pattern is always the same. You do one syscall to check something about a path, then another syscall to act on the same path. Between those two calls, an attacker with write access to a parent directory can swap the path component for a symbolic link. The kernel re-resolves the path from scratch on the second call, and the privileged action lands on the attacker’s chosen target.
It's actually even worse than that somewhat, because the attacker with write access to a parent directory can mess with hard links as well... sure, it only messes with the regular files themselves but there is basically no mitigations. See e.g. [0] and other posts on the site.
[0] https://michael.orlitzky.com/articles/posix_hardlink_heartache.xhtml
Piraty · 2026-01-27
philipwhiuk · 2025-10-14
Notable prior submission: https://news.ycombinator.com/item?id=37262457
Also by the author: https://michael.orlitzky.com/articles/in_defense_of_self-signed_certif…
alphabet9000 · 2022-11-30
yes certainly, this page would be good to link to: http://michael.orlitzky.com/articles/lets_not_encrypt.xhtml (not my writing, but i appreciated the sentiment of it)
cristoperb · 2021-07-06
The author links to one example at the top of the article ("CVE-2017-18188: opentmpfiles root privilege escalation via recursive chown"):
http://michael.orlitzky.com/cves/cve-2017-18188.xhtml
Apparently a user can create a hardlink to a sensitive root-owned file (like /etc/shadow) in a user-writable directory where they know a privileged process (in this case tmpfiles.d) will come along and chown it to the user, after which that user will own the sensitive file too.