Incorrect report of non-executable rustup-init binary in latest Ubuntu Docker container: "Please copy the file to a location where you can execute binaries and run ./rustup-init"

[jrop]

Problem
rustup-init.sh reports "Please copy the file to a location where you can execute binaries and run ./rustup-init", however when I ls the file (and furthermore, try to execute it), it is indeed executable.

This started happening in the ubuntu:21.04 Docker container with image hash: 1fc773f9e714.

Steps

1. docker run --rm -it ubuntu@sha256:2fc51f401cb873bfec33022d065efacbaf868b2e23f4dd76d7230d129258e255 bash
2. apt update && apt install curl -y
3. curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y

Possible Solution(s)

I added set -x to the downloaded script, and did not see anything obvious, though it does seem fairly evident that the call to test -x "$_file" is incorrectly reporting that the file is not executable: ls -l $_file shows that the file is indeed executable, and I am able to run the file manually. 🤷

[kinnison]

The script you fetch with curl determines which, and then downloads the binary for rustup-init (rustup) and tries to run it. If the temporary directory it downloads to is mounted noexec then it won't work. I wonder how come you can run it manually but not if it's downloaded by the script and run by the script.

I'm afraid I don't have docker myself so I can't directly diagnose this. All I can suggest is that you look at where the rustup-init is downloaded to and whether there's any odd mount limits there.

[jrop]

So I was having all sorts of issues with that Ubuntu image: ubuntu@sha256:2fc51f401cb873bfec33022d065efacbaf868b2e23f4dd76d7230d129258e255, which is the ubuntu:21.04 image as of 2/23/2021

I could not run any Cargo commands that ended up doing anything Git-related, as I got similar errors. For example:

root@aa6c22a9d99b:/# cargo new hello-world --bin
error: Failed to create package `hello-world` at `/hello-world`

Caused by:
  failed to resolve path '/hello-world/.git/': Operation not permitted; class=Os (2)

(that error seems to originate from libgit2)
Also, when searching around on the forums, it appears that another Docker + Cargo user recently ran into this issue as well, except on recent versions of the Arch Linux Docker image:

• https://users.rust-lang.org/t/permission-problems-on-arch-linux-docker-container-on-github-workflow/55292
• https://github.community/t/docker-actions-operation-not-permitted-when-running-git-clone-in-working-directory/160294

I'm wondering if there was a recent change in both the Arch/Ubuntu container images that is causing something else to go on? When I switched to node:12 as my base image, everything is hunky dory.

[jrop]

Also, from what I can tell, nothing looks screwy with the mount list:

root@aa6c22a9d99b:/# mount
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/2DCMKQJTSHRE264L4JFATTXVGB:/var/lib/docker/overlay2/l/TDNKCG4SIHTAXWGXVDFXPLYGXV:/var/lib/docker/overlay2/l/ABKH7I2QKKYDMGIM2KXJ6TA44G:/var/lib/docker/overlay2/l/IYFUEFQWZGIXVG2YRYGSIQV2OZ,upperdir=/var/lib/docker/overlay2/03886df27014bdaed5d925a04994b6c835ca5c5a6490f6b92888aec48baebca4/diff,workdir=/var/lib/docker/overlay2/03886df27014bdaed5d925a04994b6c835ca5c5a6490f6b92888aec48baebca4/work)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
blkio on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
memory on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
devices on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
freezer on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
net_cls on /sys/fs/cgroup/net_cls type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls)
perf_event on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
net_prio on /sys/fs/cgroup/net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_prio)
hugetlb on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
pids on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
rdma on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,name=systemd)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
/dev/vda1 on /etc/resolv.conf type ext4 (rw,relatime)
/dev/vda1 on /etc/hostname type ext4 (rw,relatime)
/dev/vda1 on /etc/hosts type ext4 (rw,relatime)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
proc on /proc/bus type proc (ro,relatime)
proc on /proc/fs type proc (ro,relatime)
proc on /proc/irq type proc (ro,relatime)
proc on /proc/sys type proc (ro,relatime)
proc on /proc/sysrq-trigger type proc (ro,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /sys/firmware type tmpfs (ro,relatime)

[kinnison]

Is, perhaps, the $HOME set to / and is / not writable in some fashion perhaps? All in all this is sounding like a docker-specific problem. If you can come up with a fix, it would be handy to update this issue so that others can find it.

[workingjubilee]

@rustbot label: +O-containers