Preserve group write bits in shared source caches

[vwxyzjn]

Why?

On Unix, uv's cache can live in a group-writable shared directory, such as a setgid cache on a multi-user machine. Source archives and build backends can still materialize extracted files or built wheels with explicit 0644 modes before uv publishes them into the cache, leaving those artifacts non-group-writable for other cache users.

How?

• Detect shared cache destinations by checking whether the cache parent is group-writable.
• Before publishing extracted source trees or built wheels into the source-distribution cache, preserve group access by adding group write to files and group write/setgid to directories.
• Repair cached source trees after successful wheel or metadata builds, since build backends can mutate cached sdists in-place by writing files like *.egg-info/PKG-INFO.
• Leave private cache parents unchanged and cover both shared and private cases with Unix unit tests.

Test plan

• cargo fmt --package uv-distribution --check
• cargo test -p uv-distribution cache_parent
• Manual Linux repro with a 2775 fresh UV_CACHE_DIR: stock uv left sgmllib3k.egg-info/PKG-INFO as 644; this branch leaves both PKG-INFO files as 664 and reports BAD_COUNT=0 for find "$cache/sdists-v9" -type f ! -perm -020.

Generated with Codex: https://openai.com/codex

[EliteTK]

Broadly speaking we shouldn't be overriding the umask. We already do that for file locks and it's causing no end of annoyance.

If you are using directories with setgid set but your umask is 0022 then this problem will exist in all other software.

Maybe as an opt in, but even then, it would require thought in terms of design and though in terms of the implementation.

[charliermarsh]

I haven't looked at the change yet, but some relevant prior art for us to consider (along with the linked PRs):

• shared uv cache: metadata.msgpack gets too restrictive perms for built-wheels #5496
• shared env: executables perms problem on install #5581

[EliteTK]

After some internal discussion, it sounds like this happens with the umask correctly set to 0002.

I am not sure about the approach of doing it retroactively, although it might be unavoidable to some extent as you identified. But the approach should ignore the directory permissions and only care about the umask to avoid surprise.

I will investigate this further.

[EliteTK]

An option might be to wipe the src directory after a build. We should only be re-using it in limited circumstances, so the impact should not be significant for 99% of usecases. Will keep investigating.