Running rust-analyzer without write access to disk

[grothesque]

Given the serious security implications of using rust-analyzer, I am running it within a bubblewrap sandbox without network access and with limited disk access. I am not the only one to sandbox rust-analyzer in this way: https://users.rust-lang.org/t/does-rust-analyzer-need-more-crates-than-building/120398, https://gist.github.com/janvhs/eb32db927d394c7744d9e2367b5fe406

I attach the wrapper script that works for me below.

So far, I have not managed to get rust-analyzer to run without write access to the workspace directory. I understand that this is related to rust-analyzer using cargo under the hood, and cargo not being designed to work on a read-only file system.

Still, I believe that many users of rust-analyzer expect it to only ever read data (and be safe) by default. I believe that it is conceivable for rust-analyzer to be designed in such a way that it only ever looks behind the user’s shoulder, but never ever writes anything to disk. (That would mean that some code could not be analyzed before it has been compiled, say, but so be it.)

The purpose of this issue is to inquire whether such a safer mode of operation wouldn’t be a reasonable default. I understand that such a wide-ranging change is difficult to implement, but perhaps this could be a long-term goal? Alternatively, are there ways in which concerned users can run rust-analyzer without write access to disk today?

Here is my wrapper script:

#!/bin/sh

# This script is NOT meant to be generic. It is meant for a specific user only,
# and needs to be adapted.  In particular, the necessary home directory bindings
# are user-specific.

set -eu

home=/home/USERNAME
cargo_home=$home/.cargo
rustup_home=$home/.rustup

# Determine the workspace directory.  Use the current directory as fallback.
if workspace=$(/usr/bin/cargo locate-project --workspace --message-format=plain 2>/dev/null); then
    workspace=$(dirname -- "$workspace")
else
    workspace="$(pwd)"
fi

# We bind the workspace read-write, since rust-analyzer unfortunately does not
# support working on a read-only filesystem:
# https://github.com/rust-lang/cargo/issues/10096
#
# Network access is disabled.
exec /usr/bin/bwrap \
     --unshare-all \
     --new-session \
     --die-with-parent \
     --ro-bind /usr /usr \
     --symlink usr/bin /bin \
     --symlink usr/lib /lib \
     --symlink usr/lib64 /lib64 \
     --proc /proc \
     --dev /dev \
     --tmpfs /tmp \
     --ro-bind /etc/alternatives /etc/alternatives \
     --ro-bind "$home/something" "$home/something" \
     --ro-bind "$home/something_else" "$home/something_else" \
     --ro-bind "$rustup_home" "$rustup_home" \
     --ro-bind "$cargo_home" "$cargo_home" \
     --bind "$workspace" "$workspace" \
     --setenv CARGO_NET_OFFLINE true \
     /usr/bin/rust-analyzer "$@"

[ChayimFriedman2]

We cannot implement this feature as long as Cargo does not support this mode.

[grothesque]

My intention in opening this issue as a feature request was to discuss whether the problems I named above are perceived as real problems and whether they are worth tackling (in whatever way). If the consensus turns out to be that these are real problems but addressing them requires modifications to Cargo, then this is already something that can be discussed with the Cargo people.

By closing this issue as “not planned” you make this arguably important security problem less visible. I believe that it deserves some discussion even if there might be no easy solutions right now.

This is also related to #12499, so I mention it here.

[ChayimFriedman2]

Sorry, I didn't mean to close this. I'm just saying that there is no point in discussing it when there is nothing we can do. If you reach out to the Cargo people and they'll ask "is this is a requirement for r-a supporting this?" then you can answer that yes, it is. Otherwise, you need to convince them, not us.