use confstr(_CS_DARWIN_USER_TEMP_DIR, ...) as a TMPDIR fallback on Darwin

[thomcc]

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.

[rust-highfive]

r? @m-ou-se

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

[thomcc]

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]

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

[thomcc]

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.

[rustbot]

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]

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

[bors]

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

[edmorley]

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

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

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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]

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

[rfcbot]

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.

[dtolnay]

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.