-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use confstr(_CS_DARWIN_USER_TEMP_DIR, ...)
as a TMPDIR
fallback on Darwin
#100824
Conversation
r? @m-ou-se (rust-highfive has picked a reviewer for you, use r? to override) |
This is a behavioral change so should go through FCP probably. See #100196 (comment) and #100196 (comment) for some of the motivation. I'll also clean up the |
☔ The latest upstream changes (presumably #102450) made this pull request unmergeable. Please resolve the merge conflicts. |
ee1c648
to
ebc6401
Compare
d294b1f
to
49dbfa9
Compare
This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...). Specifically, this changes it so that iff The motivations here are two-fold:
It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior. |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
☔ The latest upstream changes (presumably #103471) made this pull request unmergeable. Please resolve the merge conflicts. |
49dbfa9
to
f8768db
Compare
☔ The latest upstream changes (presumably #105328) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@thomcc Hi! We would love to see this land - is this in an FCP queue, or does it need to be manually submitted to that process? |
@rust-lang/libs-api: Relevant reading:
Link 2 is compelling as to why this PR is the best solution. Link 1 lists our other options, neither of which is better. |
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll also clean up the
#[cfg(target_vendor = "apple")]
to be the OSes in question and move it out of a draft PR, when I make the change following the API being available in libc.
Waiting for this (quoted from #100824 (comment)).
LGTM as soon as the cfg is fixed.
@thomcc any updates on this? thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@madsmtm yes feel free to do that :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've submitted #131505
// If the value returned by `confstr` is greater than the len passed into | ||
// it, then the value was truncated, meaning we need to retry. Note that | ||
// while `confstr` results don't seem to change for a process, it's unclear | ||
// if this is guaranteed anywhere, so looping does seem required. | ||
while bytes_needed_including_nul > buf.capacity() { | ||
// We write into the spare capacity of `buf`. This lets us avoid | ||
// changing buf's `len`, which both simplifies `reserve` computation, | ||
// allows working with `Vec<u8>` instead of `Vec<MaybeUninit<u8>>`, and | ||
// may avoid a copy, since the Vec knows that none of the bytes are needed | ||
// when reallocating (well, in theory anyway). | ||
buf.reserve(bytes_needed_including_nul); | ||
// `confstr` returns | ||
// - 0 in the case of errors: we break and return an error. | ||
// - The number of bytes written, iff the provided buffer is enough to | ||
// hold the entire value: we break and return the data in `buf`. | ||
// - Otherwise, the number of bytes needed (including nul): we go | ||
// through the loop again. | ||
bytes_needed_including_nul = | ||
unsafe { libc::confstr(key, buf.as_mut_ptr().cast::<c_char>(), buf.capacity()) }; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not entirely clear to me why we do all this work, it seems like just using a static [u8; PATH_MAX]
would be sufficient, and in any case, we can always just fall back to /tmp
if not.
But regardless, this works, and I guess there's not much harm in it, so I won't belabour the point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsure about the loop but the retry is also done by Swift's implementation of this: https://github.com/swiftlang/swift-corelibs-foundation/blob/2d23cf3dc07951ed2b988608d08d7a54cc53b26e/Sources/Foundation/NSPathUtilities.swift#L38
…olnay use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin Rebased version of rust-lang#100824, FCP has completed there. Motivation from rust-lang#100824 (comment): > This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...). > > Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before). > > The motivations here are two-fold: > > 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user). > 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`. > > It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior. Closes rust-lang#99608. Closes rust-lang#100824. `@rustbot` label O-apple T-libs-api r? Dylan-DPC
…olnay use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin Rebased version of rust-lang#100824, FCP has completed there. Motivation from rust-lang#100824 (comment): > This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...). > > Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before). > > The motivations here are two-fold: > > 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user). > 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`. > > It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior. Closes rust-lang#99608. Closes rust-lang#100824. `@rustbot` label O-apple T-libs-api r? Dylan-DPC
…olnay use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin Rebased version of rust-lang#100824, FCP has completed there. Motivation from rust-lang#100824 (comment): > This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...). > > Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before). > > The motivations here are two-fold: > > 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user). > 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`. > > It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior. Closes rust-lang#99608. Closes rust-lang#100824. ``@rustbot`` label O-apple T-libs-api r? Dylan-DPC
…olnay use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin Rebased version of rust-lang#100824, FCP has completed there. Motivation from rust-lang#100824 (comment): > This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...). > > Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before). > > The motivations here are two-fold: > > 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user). > 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`. > > It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior. Closes rust-lang#99608. Closes rust-lang#100824. `@rustbot` label O-apple T-libs-api r? Dylan-DPC
Rollup merge of rust-lang#131505 - madsmtm:darwin_user_temp_dir, r=dtolnay use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin Rebased version of rust-lang#100824, FCP has completed there. Motivation from rust-lang#100824 (comment): > This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...). > > Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before). > > The motivations here are two-fold: > > 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user). > 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`. > > It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior. Closes rust-lang#99608. Closes rust-lang#100824. ``@rustbot`` label O-apple T-libs-api r? Dylan-DPC
Followup to #100196
but should wait on rust-lang/libc#2883 before anything is done with it.(Edit: Now it needs rust-lang/libc#2931... sigh)See #100824 (comment) for an explanation of the change this makes and why I think this is worth doing.
Closes #99608.