Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

thomcc
Copy link
Member

@thomcc thomcc commented Aug 20, 2022

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.

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Aug 20, 2022
@rust-highfive
Copy link
Collaborator

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 20, 2022
@thomcc thomcc added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 20, 2022
@thomcc
Copy link
Member Author

thomcc commented Aug 20, 2022

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 #[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.

@bors
Copy link
Contributor

bors commented Sep 29, 2022

☔ The latest upstream changes (presumably #102450) made this pull request unmergeable. Please resolve the merge conflicts.

@thomcc thomcc added needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 29, 2022
@thomcc thomcc force-pushed the darwin_user_temp_dir branch 3 times, most recently from d294b1f to 49dbfa9 Compare September 29, 2022 13:02
@thomcc
Copy link
Member Author

thomcc commented Sep 29, 2022

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, 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.

@thomcc thomcc marked this pull request as ready for review September 29, 2022 13:14
@rustbot
Copy link
Collaborator

rustbot commented Sep 29, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@bors
Copy link
Contributor

bors commented Oct 24, 2022

☔ The latest upstream changes (presumably #103471) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Nov 22, 2022
@bors
Copy link
Contributor

bors commented Dec 6, 2022

☔ The latest upstream changes (presumably #105328) made this pull request unmergeable. Please resolve the merge conflicts.

@albertlarsan68

This comment was marked as off-topic.

@rustbot rustbot removed the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Jan 18, 2023
@edmorley
Copy link
Contributor

@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?

@dtolnay dtolnay assigned dtolnay and unassigned m-ou-se Jan 26, 2024
@dtolnay
Copy link
Member

dtolnay commented Jan 26, 2024

@rust-lang/libs-api:
@rfcbot fcp merge

Relevant reading:

  1. env::temp_dir returns /private/tmp on Apple instead while /tmp is #100196 (comment)
  2. env::temp_dir returns /private/tmp on Apple instead while /tmp is #100196 (comment)
  3. Consider returning /private/tmp instead of /tmp on macOS with std::env::temp_dir() #99608 (comment)

Link 2 is compelling as to why this PR is the best solution. Link 1 lists our other options, neither of which is better.

@rfcbot
Copy link

rfcbot commented Jan 26, 2024

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.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jan 26, 2024
@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 20, 2024
@rfcbot
Copy link

rfcbot commented Feb 20, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Mar 1, 2024
@rfcbot
Copy link

rfcbot commented Mar 1, 2024

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.

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Mar 7, 2024
Copy link
Member

@dtolnay dtolnay left a 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.

@Dylan-DPC
Copy link
Member

@thomcc any updates on this? thanks

Copy link
Contributor

@madsmtm madsmtm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bump @thomcc?

I can rebase, fix the remaining #[cfg(target_vendor = "...")] and submit an updated PR if you want?

@rustbot label O-apple

@rustbot rustbot added the O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) label Oct 10, 2024
@Dylan-DPC
Copy link
Member

@madsmtm yes feel free to do that :)

Copy link
Contributor

@madsmtm madsmtm left a 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

Comment on lines +600 to +619
// 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()) };
}
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compiler-errors added a commit to compiler-errors/rust that referenced this pull request Nov 22, 2024
…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
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Nov 22, 2024
…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
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Nov 23, 2024
…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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 23, 2024
…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
@bors bors closed this in f860f5b Nov 23, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 23, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider returning /private/tmp instead of /tmp on macOS with std::env::temp_dir()