remove realpath() from the standard library #19353
Comments
andrewrk
added
breaking
|
+1 Using this function is almost always a bug, but it is not a common knowledge (someone needs to write "realpath considered harmful" blog post). At the same time, this function lies on the path of the least resistance for a lot of problems, and routinely sneaks into all kinds of places where it is completely inappropriate. I like that the function is preserved in the source code as compileError with an explnanatory comment. I think the comment could be better though: I'd remove the bit about "naivety", as knowing that realpath is not good is expert knowledge: in my career, I've seen this clearly articulated only twice: once in an off-hand remark by alexcrichton, and the second time in the Zig community. And I would include a bit of positive guidance here, which can be lifted straight out of the PR description. So, something along the lines of
If we remove this function, I'd love to see #5190 fixed, as it is one of the cases where |
I could certainly write a blog post but I'd need some sources lol. On another note, I don't really understand what makes realpath not portable and a problem. Is it mainly a Windows issue? |
|
on the portability, my guess is openbsd because windows can do it and #6718 exists; so it wouldn't surprise me if there was also difficulty in inspecting arbitrary fd's |
|
I have no real opinion on removing the API from There's also |
|
How to prevent path traversal attack without |
|
@GalaxySnail |
|
What would be an alternative to Assuming i only have a I guess if we deprecate that function, we should provide the users with a set of better alternatives instead of just claiming why it's a bug and that we do not support it. |
|
I interpreted the messaging as that the use cases that still need it should use a 3rd party module |
My understanding of how a "proper" program is supposed to handle this situation (please correct me if I'm mistaken) is that because you have a If the path you want to pass to the C library function is absolute, just pass that path verbatim. If the path you want to pass is relative, if your dir handle is the cwd you pass that path verbatim, otherwise, you pass the result of This should work for well-behaving external libraries. If the external library is poorly designed and only accepts absolute paths or paths relative to some hard-coded but unknown directory, you have to implement the required path transformation logic yourself in a way that makes the most sense for the OSes you're targeting. |
That's exactly the point. If i'm writing a library, i don't. I just receive a dirhandle+path, but no information if it's cwd-relative, root or anything, so the only two options are the ones i stated, at least to my knowledge. I cannot work on a "string" level of paths, because i don't know the root |
- zig build -Dtarget=wasm32-wasi -Doptimize=ReleaseSmall -Dno-langref -Dno-lib - Based on https://github.com/eliot-akira/zig-playground/blob/main/zig-wasm.md - Still need to resolve errors with realpath() being removed - See [remove realpath() from the standard library](ziglang#19353)
+1 regarding #5190 Not only is this naive programmer using realpath as the only way I can figure out how to spawn a windows process that uses std.testing.tmpDir - but I'm duplicating some of the path info from within that (.zig-cache/tmp..) as I couldn't figure out how to use realpath on the .dir member of the returned TmpDir struct The path from naivety to understanding is very unclear to me. |
I am not sure what you mean here: Do you have a In this case I would be confused what to do either way (with or without So, if you want an absolute path, get your current absolute path ( Sure, it's annoying, and I kinda except |
…outer parts in router directory. + Define routes at compile-time. + Add router user data, usable from context. * Adapt routes for fully compile-time definitions, without runtime data handling. * Change serve_fs_dir to use resolve instead of realpath (see ziglang/zig#19353). - Remove per-route user data. WIP: filesystem serve.
…outer parts in router directory. + Define routes at compile-time. + Add router user data, usable from context. * Adapt routes for fully compile-time definitions, without runtime data handling. * Change serve_fs_dir to use resolve instead of realpath (see ziglang/zig#19353). - Remove per-route user data. WIP: filesystem serve.
|
I just wanted to add a note to this one, regarding testing and logging. Imagine you are accepting a dir/path (for example from a config file or an end user) or defaulting to Imagine you need to pass (for example), the I understand in theory that realpath is not ideal. But in the real world I think this might cause problems. But of course, I may just be misunderstanding something and there are easy answers to this question. |
|
To add to the list of problems, it produces |
This function is not portable, relies on a legacy permissions model, cannot handle arbitrarily nested file system paths, and is therefore typically a bug to call. Yet, many programmers reach for this function out of naivety. To prevent it from cropping up in various codebases, and causing an overall degradation of software quality, omit it from the Zig Standard Library.
Currently used by the zig compiler in several places:
All of these instances have to do with debug info, except for the last line which I kept for the humor value. They are indeed all bugs. The problem is that the debug info in an executable needs to refer to the file paths of source locations, and if it uses relative paths, then a debugger looking at a moved executable will not be able to find the source files.
However, it is still incorrect to attempt a transformation of a relative path to an absolute path. Instead, the compiler needs to take note of the file paths passed in by the user. These strings must be retained whether absolute or relative, and used, rather than trying to resolve the path based on the file descriptor.
This pushes the problem back into the build system which constructs the CLI for the compiler. But that's precisely how to solve this problem - push it as far back as possible, until there is exactly one realpath() transformation done at the very beginning of the software, ideally by the user themselves.
I expect this to be a controversal proposal.
The text was updated successfully, but these errors were encountered: