Linux toolchain unpack leaves bin/* without execute permission (644)

[AlexMikhalev]

Summary

After rustup update / toolchain install on Linux, binaries under $RUSTUP_HOME/toolchains/*/bin/ can be installed with mode 644 (-rw-r--r--) instead of 755, causing immediate failures:

error: Permission denied (os error 13)

when invoking cargo, rustc, rustfmt, etc.

Environment

• OS: Linux x86_64 (ext4)
• rustup: 1.29.0 (28d1352 2026-03-05)
• RUSTUP_HOME: ~/.rustup (default)
• umask: 022
• Reproduced: 2026-06-08 after rustup update stable

Steps to reproduce

rustup --version
rustup update stable   # or: rustup toolchain install stable

find "$RUSTUP_HOME/toolchains" -path '*/bin/*' -type f ! -perm -111 -print | head
stat -c '%a %n' "$RUSTUP_HOME/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo"

cargo --version   # may fail with os error 13 if 644

Expected behaviour

Toolchain binaries under toolchains/*/bin/ are executable (mode includes +x, typically 755 with umask 022).

Actual behaviour

Some or all toolchain bin/* files are 644. The rustup shim itself remains executable; only unpacked toolchain components are affected.

Impact

Breaks CI runners and automation that calls cargo/rustfmt immediately after a toolchain refresh.

Workaround

find "$RUSTUP_HOME/toolchains" -path '*/bin/*' -type f ! -perm -111 -exec chmod +x {} +

Additional notes

• Default ~/.rustup was used (no custom relocation).
• Historical toolchains on the same host also showed 644 on bin/*, suggesting unpack/install rather than backup restore.

[rami3l]

@AlexMikhalev Hello, as far as I know rustup's logic of determining the FS permissions of unpacked files is as follows, based on the tar_mode:

rustup/src/dist/component/package.rs

Lines 330 to 339 in 835392d

	let tar_mode = entry.header().mode().ok().unwrap();
	// That said, the tarballs that are shipped way back have single-user
	// permissions:
	// -rwx------ rustbuild/rustbuild ..... release/test-release.sh
	// so we should normalise the mode to match the previous behaviour users
	// may be expecting where the above file would end up with mode 0o755
	let u_mode = tar_mode & 0o700;
	let g_mode = (u_mode & 0o0500) >> 3;
	let o_mode = g_mode >> 3;
	let mode = u_mode | g_mode | o_mode;

This means only a tar with mode 0o6xx in the header can generate 0o644 files. In other words, it doesn't look like a rustup problem, but a problem with the files it downloads.

Is there anything special about your setup in that regard? Are you downloading from a corporate archive of Rust releases? Are you downloading nightlies? Stables should be quite hard to have that problem, otherwise many must have noticed already.