Synchronized FFI access to POSIX environment variable functions
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed. Read full topic
View ArticleSynchronized FFI access to POSIX environment variable functions
Arguably this definitely had no safety condition before, since it was a safe function. The fact that this spec was wrong doesn't change that this is the spec we communicated to our users, so cleaning...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: new safety condition Arguably the safety condition has always existed; it's just documented now. Read full topic
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
josh: As soon as #[deprecated_safe] is available, I think we should use that on the existing functions, and continue having that be our interface to the environment. One issue with deprecated_safe:...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: env::remove_var will no longer modify the environment passed to fork/exec I did not suggest to change the behavior of env::remove_var like that, and I would not be in favor of such a change....
View ArticleSynchronized FFI access to POSIX environment variable functions
@bjorn3 but the main problem here is FFI use cases. A C library wrapped via an FFI binding can call fork/exec, in which case it might use the system environment, not the shadow environment. And if...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
mjbshaw: I think the important part is that they're removed before forking so the forked process can't read them after execing. It doesn't matter if env vars are removed before or after forking as...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: Here's an example of the hoops people have jumped through to unset system environment variables in Java: Note that env::remove_var will still be available, you'll just need to make sure it is...
View ArticleSynchronized FFI access to POSIX environment variable functions
I think the important part is that they're removed before forking so the forked process can't read them after execing. Read full topic
View ArticleSynchronized FFI access to POSIX environment variable functions
Could cargo-miri's use case be covered by a crate? If so a shadow-env crate could be published and the migration guide could point people at the new APIs for the common cases and to the crate for...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: and from a security perspective might give the impression that secrets (which really shouldn't be kept in environment variables , but that ship has sailed and I digress) have been removed...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: I wasn't aware of this being a problem in practice, do you have a reference for that? Here's an example of the hoops people have jumped through to unset system environment variables in Java:...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: from a security perspective might give the impression that secrets (which really shouldn't be kept in environment variables , but that ship has sailed and I digress) have been removed from...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: In an ideal world we wouldn't have such a shadow environment. If I we could un-do having these safe methods in Rust 1.0 we should do it. I'll +1 @josh re: somewhat strong opposition to a...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: Also even if this is a Rust command-calling library It is. RalfJung: hat's really a bug in that command-calling library and needs to be fixed there. Yeah, seems like if we want to help...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: The reason I suggested thread local is I came across a PR that wanted to use external command-calling library together with set_var. Ofc I immediately pointed out that this was bad in...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Indeed, that's why I suggested making it thread-local. However as @RalfJung said: its one and only purpose -- to port existing code. I didn't think of it in this way before but now realized that...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: I reminds me of situation with mem::uninit which some crates used as a (subjectively horrible) hack to implement unreachable_unchecked. Turning it to panic was technically breaking change...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: If there isn't you actually don't know if "it happened" - it may have been overwritten in the other thread right after you wrote (even with "safe" locking), so the behavior already is...
View ArticleSynchronized FFI access to POSIX environment variable functions
If there is a single thread then it did happen. If there isn't you actually don't know if "it happened" - it may have been overwritten in the other thread right after you wrote (even with "safe"...
View Article
/pic9814888.png)
/fit-in/580x348/filters:format(webp)/english-betterindia/media/media_files/2026/09/17/balaghat-3-2026-09-17-18-46-40.png)
