[Solved] Quasi transient std::env::current_dir() error

Hiya! I need help.

I hit an issue on Ubuntu where std::env::current_dir() is returning a Permission denied error, but I haven't been able to trace the cause.

Full investigation details are on sagiegurari/cargo-make#81 , the summary points:

  • I'm using cargo-make to run a script.
  • cargo-make eventually calls std::env::current_dir(), and that returns a EACCES error (permission denied).
  • The directory exists, I can reproduce the error by running cargo-make as the gitlab-runner user inside the directory itself.
  • The directory and all its parent dirs are owned by that user.
  • The first time this error happened was on my gitlab-runner user during a build, but it has happened once to my normal user yesterday.
  • This is a transient error, but consistently happens once it has happened (it goes away when I restart my computer, for example, but somehow comes back later).
  • Writing a trivial program that calls std::env::current_dir() and printing it, during the time the error can be reproduced, works.

This happened when cargo-make has been compiled with stable (1.24.1) or nightly-2018-03-16-x86_64-unknown-linux-gnu. The issue also still happens when the active toolchain is switched to stable or the latest nightly (nightly-2018-03-19), which suggests the issue is neither: which version of Rust was used to compile cargo-make, or the active toolchain.

I can't tell where along this stack the problem lies, so it's hard to choose where to raise an issue:

  • My laptop
  • Ubuntu
  • gitlab-runner
  • Rust (probably not?)
  • Cargo
  • cargo-make

Thanks to @zomerfaun on the rust-lang/rust gitter chat, traced it (literally, straced) it to cargo-make using a common directory in /tmp (which it subsequently did not delete); not the current_dir() call that I thought it was failing on.

Since /tmp has the sticky bit set, and my user and the CI runner are on the same machine, whoever ran the tool first had permissions to the directory.

We shall fix it!