`tempfile` creates every temp file 0600, and `pnpm_fs::write_atomic`
kept that for new files, so any writer that didn't think about modes
left project files owner-only: `pnpm-workspace.yaml` (an edit also
tightened an existing file), `pnpm deploy` output, patch files, the patch
state, the lockfile `dedupe --check` restores, `.cargo/config.toml`, and
every new file written through `write_atomic`. A Docker image built as
root and run as another user could not read them. pnpm 11 follows the
umask.
- `write_atomic` gives a new file 0666 less the umask; an existing file
keeps its mode, and its replacement is staged at that mode so the
contents never become readable by more users.
- `write_atomic_private_if_new` keeps 0600-when-new for files that may
hold a credential: `.npmrc`/`auth.ini` from `pnpm config set`, and
caches of URLs that can carry userinfo (tarball HTTP, Python index and
wheel, Cargo sparse registry, pnpr upstream indexes).
- `write_atomic_private` is unchanged.
- The hand-rolled private-temp-file writers in dedupe, patch-commit,
patch state and deploy call `write_atomic`; package-manifest and pack
stage at the existing mode through `named_tempfile_with_mode_in`.
- clippy `disallowed-methods` rejects `NamedTempFile::new_in` and
`Builder::tempfile_in` outside the `pnpm_fs` helpers, so new writers
must choose a mode.
- A CLI test runs install, patch and patch-commit under umask 022 and
fails on any owner-only file in the project.
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
