{workspace-path-hash} directory permission issues in multi-user environments

[kornelski]

Problem

If build-dir is set globally to something like /var/tmp/cargo/{workspace-path-hash}, different users sharing the same system will run into directory permission issues, even if /var/tmp/cargo/ itself is world-writeable.

{workspace-path-hash} expands to two directory levels like ab/cdef. Cargo creates the first part with the current user's ownership. This ends up preventing other users from writing to the ab/ directory, even if the complete hash of their workspace is different, and shares only the prefix (like ab/5678). When different local users are involved, the hash is effectively just one byte and collides quickly.

Steps

rustup default nightly
export CARGO_BUILD_BUILD_DIR="/var/tmp/cargo/{workspace-path-hash}"
for n in `seq 1 30`; do
    useradd testuser$n
done
mkdir -p /var/tmp/cargo tests
chmod a+rwX /var/tmp/cargo tests
cd tests
set -e
for c in `seq 1 10`; do
    for n in `seq 1 30`; do
        runuser -u testuser$n -- bash -c 'CRATE=x$UID-$RANDOM-$RANDOM; cargo new --lib $CRATE -q; cd $CRATE; cargo b' 
    done    
done

Possible Solution(s)

• make {workspace-path-hash} expand to a single path component
  • optionally adding {workspace-path-hash-prefix} to allow users recreate the workaround for poor filesystems
• add a path variable with $EUID, like {os-user-id}, which would allow global directories to be sharded by user explicitly
• make the first directory component of the hash copy access permissions from its parent directory to make the 256 dirs world-writeable too

Notes

This may be relevant in the future if Cargo switches to using system directories, and system-wide Cargo installations end up getting paths that aren't in $HOME #16147

Version

cargo 1.93.0-nightly (344c4567c 2025-10-21)

[epage]

I'd be curious to better understand your use case for putting build-dirs from different users into the same location.

This may be relevant in the future if Cargo switches to using system directories, and system-wide Cargo installations end up getting paths that aren't in $HOME #16147

Note that that issue is specifically suggesting a user-specific location, not a system-wide one.

[kornelski]

I'm setting up an internal CI environment, where I'd like to provide good defaults for Rust/Cargo builds. Removing temp files from workspaces helps speed up some other CI tasks that scan or cache build directories. I control the system-wide config (base image), but don't control individual CI jobs. Different jobs and build stages may run as different users (to keep builds from mutating files they're not supposed to, while not completely losing Cargo's cache like stateless containers would).

[ranger-ross]

I suppose you could set the build-dir via env var in ~/.profile in your setup script.

maybe something like:

...
for n in `seq 1 30`; do
    useradd testuser$n
    echo "CARGO_BUILD_BUILD_DIR=/var/tmp/cargo/testuser$n/{workspace-path-hash}" > /home/testuser$n/.profile
done
...

[kornelski]

That script is an artificial scenario, only created for this GitHub issue to help reproduce the problem.

It's possible to work around the permission issues by not sharing the build directory, but the whole point of this issue is to report inability to reliably share the build directory.