Cargo unpacks files with too restrictive mode (breaking multi-user shared cargo registry)

[vi]

I share cargo home directory between multiple user accounts and want to use cargo install from both uids. For this I want all Rust-related things to be group-writable.

But despite of umask is 0002 (new files are group-writable by default) and all directories have mode g+rwxs, some files unpacked by Cargo get usual boring mode 644, preventing clearing directories from other user later.

For example, now I see

drwxrwsr-x 6 rust rust 496 Dec 22 20:12 .multirust/toolchains/nightly/cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/clippy-0.0.104
-rw-r--r-- 1 rust rust 24K Dec 17 03:28 .multirust/toolchains/nightly/cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/clippy-0.0.104/CHANGELOG.md

Why files inside the clippy-0.0.104 directory get restrictive permissions when everything else is group-writable? Should Cargo avoid walling non-security-related files against other users when umask is explicitly configured not to do so?

[sfackler]

I believe those permissions are set in the package tarballs.

[vi]

Shall those tarballs be extracted not this literally? Maybe like in Git, it should only discriminate executable and non-executable, observing umask and sticky bits for other bits?

If tarball contains suid-bit executables, will they also be unpacked with suid bit set?

[alexcrichton]

Yes currently tarballs are extracted using the support in the tar crate which notably preserves permissions. Note that permissions are masked with 0o777 by default but this can be disabled.

It seems reasonable to me (especially if there's precedent in git) to have Cargo extract respecting umask to allow having group-readable/writable files!

[wentasah]

Is there a chance somebody will address this issue? I was just hit by it in the pin-utils crate. Issue #2948 seems related too.

[weihanglo]

There is also #9455 trying to make files read-only. Unfortunately some crates may depend on preserved file permissions already. One way to solve is to handle only *.rs and Cargo.{lock,toml} probably. However, if a package depends on other data files, things might still be broken.

[tmada]

I too am noticing this behavior that is preventing me from setting up a shared directory workspace for our dev team. ACLs won't solve this either. Any help would be greatly appreciated!

[tom@dev-04 index.crates.io-6f17d22bba15001f]$ pwd
/opt/rust/registry/src/index.crates.io-6f17d22bba15001f
[tom@dev-04 index.crates.io-6f17d22bba15001f]$ getfacl adler-1.0.2
# file: adler-1.0.2
# owner: tom
# group: dev
# flags: -s-
user::rwx
group::rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::---

[tom@dev-04 index.crates.io-6f17d22bba15001f]$ cd adler-1.0.2/
[tom@dev-04 adler-1.0.2]$ ls -l
total 46
drwxrws---+ 2 tom dev     3 Jun  6 14:50 benches
-rw-------+ 1 tom dev  2040 Jan  1  1970 Cargo.toml
-rw-------+ 1 tom dev  2084 Jan  1  1970 Cargo.toml.orig
-rw-------+ 1 tom dev  1714 Jan  1  1970 CHANGELOG.md
-rw-------+ 1 tom dev   665 Jan  1  1970 LICENSE-0BSD
-rw-------+ 1 tom dev 10860 Jan  1  1970 LICENSE-APACHE
-rw-------+ 1 tom dev  1023 Jan  1  1970 LICENSE-MIT
-rw-------+ 1 tom dev  1156 Jan  1  1970 README.md
-rw-------+ 1 tom dev   527 Jan  1  1970 RELEASE_PROCESS.md
drwxrws---+ 2 tom dev     4 Jun  6 14:50 src