[HN Gopher] How Hard Is It to Open a File?
___________________________________________________________________
How Hard Is It to Open a File?
Author : ffin
Score : 84 points
Date : 2026-04-24 02:01 UTC (2 days ago)
HTML web link (blog.sebastianwick.net)
TEXT w3m dump (blog.sebastianwick.net)
| TZubiri wrote:
| Knowing what to be concerned about in security is a skill, it is
| possible to overengineer security and put too much effort in non
| risks.
|
| This reminds me of when a student was concerned about the client
| leaking the server's ip address.
|
| Not saying that there aren't vulns, but the fix is fixing the bug
| and using a standard hardening mechanism like selinux or unix
| users. I strongly doubt that the root issue is the good old
| filesystem api everyone has been using for decades, it's more
| likely to be your code bro
| croemer wrote:
| Good explanation of the flatpak sandbox escape.
|
| For those allergic to LLM writing: Some sentences read very LLM-
| like, e.g.:
|
| > The fix wasn't "change one function" -- it was "audit the
| entire call chain from portal request to bubblewrap execution and
| replace every path string with an fd."
| jshmrsn wrote:
| Am I missing something, or do this article's purported
| vulnerabilities rely on an assumption that an attacker already
| has enough access to your system that the attacker can modify
| files which your code is referencing by path? Isn't this more of
| an escalation vector than a vulnerability in itself?
|
| I'm trying to understand the practical takeaway.
| tekacs wrote:
| It can come up as "I did not expect _arbitrary_ code
| execution/overwrite, especially not as root."
|
| e.g. in an installer: 1. Download package
| 2. Maybe 'prepare' as the user - this could be _entirely_
| caller-driven (i.e. you didn't run any code, you just provided
| materials for the installer to unpack/place/prepare), or it
| could include some light/very restricted code execution
| 3. Perform 'just one operation' such as 'copying things into
| place' (potentially with escalation/root) 4. In step 3,
| the preparation from 2 resulted in the placement of something
| in binary position (that then runs), and/or overwriting of
| important files (if something placed in step 2 was used as a
| target)
|
| I'm collapsing and simplifying - lots more possibilities and
| detail than the above.
| dnnddidiej wrote:
| I am not a sysadmin by a long stretch but I see it as asking
| another process with more priveledges to do something to a file
| on your behalf. But I would like sma practical example. Would
| docker daemon running as root be one?
| dnnddidiej wrote:
| Anyway to open the file with the permissions of the calling
| process and pass that over?
| codethief wrote:
| > https://github.com/flatpak/flatpak/security/advisories/GHSA-...
|
| Just yesterday I was thinking about a related attack vector on AI
| agents: Many harnesses "sandbox" (at the application level) file
| reads/writes and shell commands by checking whether a given path
| has been whitelisted. However, I bet there are cases where the
| agent could simply create a symlink to somewhere else and thus
| trick the "sandbox" into thinking the agent is authorized?
| adi_kurian wrote:
| Assume the worst.
| neilv wrote:
| I bet you're right. This is one kind of thing you need a
| meticulous programmer to do. But instead, I'd guess most AI-
| dogfooding engineering organizations in the near future will be
| taking a vibe-code-it-and-AI-red-team-it approach.
|
| I don't trust sandbox claims from those companies, and only run
| CLI-ish code on workstation inside a full VM (not even a
| container).
| cassianoleal wrote:
| > not even a container
|
| Genuinely curious, what specific threats are you thinking
| about when you make this choice?
| neilv wrote:
| Mainly routine software supply chain attacks to unexamined
| dependencies pulled in by a mess of vibe-coding.
|
| (Though it would also give some protection against growth
| hacking or kludge expedience that goes a little too
| naughty. We're already seeing some questionable behavior
| there, as some rush to get their functionality working
| first.)
|
| Since containers are for fairly trusted code, and
| relatively easy to break out of, compared to a good VM.
| TZubiri wrote:
| Any attempt to analyze a string that will be executed as a
| command is a fundamentally unsafe approach, presumably I can
| make an .sh file and run that and circumvent the mechanism? Off
| the top of my head. You could say that your analysis will be so
| deep that it can check the file scripts, it' can do so
| recursively through bash file chain s of any size, it's so
| smart in fact it can undecode base64 contents, and even if...
|
| No, stop, if you do that, you have entered a rabbit hole,
| ignore the command, assume it can be malicious. Path
| constraints are already fundamentally solved with tech as old
| as UNIX users, you are 50 years behind in terms of security and
| should not be concerning yourself with cutting edge issues for
| that reason.
| deadlyllama wrote:
| Before I read the linked page I assumed this was a rant about
| using MS Office with files on your local filesystem. Although
| that would be titled "How Hard is it to Save a File?"
| lapsed_lisper wrote:
| I've worked on projects with people who've insisted on these
| approaches, and I've never understood how this secures things in
| any deep way. As I understand the reasoning, open("/a/b",...) is
| discouraged in favor of openat(fd, "b", ...) because an attacker
| might be able to hijack /a. But as I see things, if an attacker
| has ever been able to hijack what /a contains or what "/a" refers
| to, they can change whatever "b" ends up naming, and the game is
| over.
|
| As for the article's glnx_chaseat(), ISTM the 8 orthogonal flag
| bits are a warning indicator. If there need to be 256 ways to
| configure pathname resolution semantics, then there are 255 ways
| the flags compiled into program can be inappropriate for any
| particular use. Even if we stipulate that there's a problem here
| that both needs solving, if those flags aren't a hint that this
| is a flaky solution, I don't know what is.
|
| So it has seemed to me as if the real security problem is the
| existence of a file system shared among unrelated sets of
| processes, and that if there is a secure alternative to that on
| existing operating systems, it probably looks more like embedding
| program configuration or data inside a program. (But this is
| handwavy: I'm envisioning stuffing data into ELF or Mach-O
| segments in signed binaries; some novel mechanism would need to
| be invented for shebang scripts.) But probably compartmentalizing
| all systems into distinct VMs is more practical than redesigning
| all software. (I would imagine that since the article's author
| works on Flatpak, they are motivated to want something less than
| VMs to serve as viable compartmentalization solutions, however.)
___________________________________________________________________
(page generated 2026-04-26 15:01 UTC)