I use Cargo for Linux under Windows Subsystem for Linux. The cargo clean command appears to attempt to remove everything from /tmp.
[2021-06-25 13:58:53]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp/cscdprox
$ find -name \*.rs -exec cat {} \;
use actix_web::{get, web, App, HttpServer, Result}; //HttpResponse
//#[actix_web::main]
fn main() {
// let localhost = "127.0.0.1:3000";
println!("http://127.0.0.1:3000");
let server = HttpServer::new(|| {
App::new().service(get_entry) });
server.bind("127.0.0.1:3000").expect("Unable to bind to 127.0.0.1:3000 - is program already running?").run();
}
#[get("/v3/content_types/{ct}/entries/{id}")]
async fn get_entry(info: web::Path<(String, String)>) -> Result<String> {
let info = info.into_inner();
Ok(format!("{0} : {1}", info.0, info.1))
}
[2021-06-25 13:59:05]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp/cscdprox
$ cat cargo.toml
[package]
name = "cscdprox"
version = "0.1.0"
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
#actix = "0.11.0-beta.2"
#actix-web = "4.0.0-beta.3"
#actix-rt = "2.0.2"
actix = "0.11.0"
actix-web = "3.3.2"
actix-rt = "1.1.1"
serde = { version = "1.0.123", features = ["derive"] }
[2021-06-25 13:59:12]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp/cscdprox
$ cargo clean
error: could not remove build directory
Caused by:
failed to remove file `/tmp/rider/jetbrains-toolbox-1.20.8804/jetbrains-toolbox`
Caused by:
Permission denied (os error 13)
[2021-06-25 13:59:34]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp/cscdprox
$ ls -ltra /tmp
total 64
drwxr-xr-x 3 jw jw 4096 Jun 4 17:39 gimp
drwxr-xr-x 3 jw jw 4096 Jun 4 19:38 fileCeKTCE.04p16
drwxr-xr-x 4 jw jw 4096 Jun 19 05:47 rustmod
drwx------ 2 jw jw 4096 Jun 20 07:25 .com.google.Chrome.n23n6s
drwxr-xr-x 4 jw jw 4096 Jun 21 06:03 rum
drwxr-xr-x 3 jw jw 4096 Jun 23 09:02 rider
drwx------ 2 jw jw 4096 Jun 23 09:03 .mount_jetbraK3sBdB
-rw-r----- 1 jw jw 0 Jun 23 09:03 qipc_systemsem_semcddacfeaacbdae69d8bfb06a2746b30e1b1f4496dd67aa5377d3a4
-rw-r----- 1 jw jw 0 Jun 23 09:03 qipc_sharedmemory_cddacfeaacbdaecffb74970e03b6e1386fd4c5012c6c70aba839a0
-rw-r--r-- 1 jw jw 0 Jun 23 09:06 env16293231419267590625.xml.err
drwx------ 2 jw jw 4096 Jun 23 09:30 JetBrainsPerUserTemp-1000-1
prwx------ 1 jw jw 0 Jun 23 09:30 clr-debug-pipe-4129-890038-in
drwxr-xr-x 2 jw jw 4096 Jun 23 09:31 hsperfdata_jw
drwxr-xr-x 19 root root 4096 Jun 25 13:11 ..
lrwxrwxrwx 1 root root 19 Jun 25 13:11 .X11-unix -> /mnt/wslg/.X11-unix
drwxrwxrwt 11 root root 20480 Jun 25 13:59 .
[2021-06-25 13:59:47]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp/cscdprox
$
This process has certainly removed files and subdirectories from my /tmp directory. Is there an environment variable or something that I should beware?
Link to a build script I was using for a different project before I had the problem, but I am leaning towards the conclusion that one of the packages caused the problem, not my edits or build processes.
I have not set that variable. This is totally unexpected and seems incredibly dangerous; it could delete anything that does not require privilege escalation, without even informing me. The only thing that I can think of is that some dependency somehow used /tmp explicitly? I do not have any references to /tmp now but if I run cargo clean it still generates the error.
Oh my gosh, is this really the default configuration of a tool that deletes everything from the specified directory? I did not make this edit, although it is possible that a package that I referenced did, because I only noticed this behavior recently, and was never aware of this file before? Nobody else has had this issue?
[2021-06-25 22:21:43]:jw@HAL9000-6WQ9TQ2:~/.cargo
$ grep /tmp ./config
target-dir = "/tmp"
[2021-06-25 22:21:56]:jw@HAL9000-6WQ9TQ2:~/.cargo
$ cp ./config ./config.default
[2021-06-25 22:22:11]:jw@HAL9000-6WQ9TQ2:~/.cargo
$ vi ./config
[2021-06-25 22:22:30]:jw@HAL9000-6WQ9TQ2:~/.cargo
$ cd
[2021-06-25 22:22:46]:jw@HAL9000-6WQ9TQ2:~
$ cd temp
[2021-06-25 22:22:49]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp
$ cd cscdprox/
[2021-06-25 22:22:52]:jw@HAL9000-6WQ9TQ2:/mnt/c/temp/cscdprox
$ cargo clean
That is the solution. I cannot believe that someone released a product like this, especially a tool like cargo with rust.
This is definitely not a default configuration option. Are you sure you didn't just forget that you changed that option? The only other situation I can think of is that someone's personal project you've used has a build script or something that sets the option in your global config file when you run it.
I think this is a very serious issue, and I do not think that it is a documentation issue. At best, this is behavior based on configuration that no developer would expect.
Cargo simply should not have the ability to delete random files from anywhere on the system, and /tmp is certainly the wrong value for this setting. Cargo should only be able to delete files that cargo created.
The /tmp value must be the default from rust/cargo or a referenced package changed it, because as I said, I did not touch this file; I did not even know that it exists. After random files started disappearing, I found it using intuition and searching for target-dir based on a comment in this post.
I did not have this problem for weeks while working with a project for which I specify the build directory not to cargo clean, but to cargo build and other commands (I would never have predicted this issue), so in addition to this variable, cargo clean may also use some metadata from previous builds, but I cannot find where it might store this.
It is possible that a library that I referenced did this, but that also should be impossible.
In my Windows install of cargo, I cannot find any such file. On Unix, target-dir is the only setting in this file.
Cargo must have set it indirectly, possibly based on something in a package. I didn't realize I was running random scripts in those packages. Also, if my local builds follow build.target-dir in the cargo.toml from a package, that seems even more dangerous than the config file, which I might be able to secure, or at least edit before builds, where editing such .toml files would be more challenging.
I think this is a very serious issue for the entire rust toolchain.
With all you have said so far, I find that the most likely explanation is that you have set the option yourself and then forgotten, or not realized in the first place. Maybe you have copy-pasted a command like this from someone who doesn't know what they are doing?
echo 'target-dir = "/tmp"' >> ~/.cargo/config
Or maybe you ran a build.sh file from someone, which contains a line like it?
Regarding security, if you are compiling unknown code, there are far easier ways to compromise your system than to set this option to a malicious value in a Cargo.toml. (note that it is ignored for dependencies)
I agree that adding a warning or error to cargo if it detects a value like this for the build directory would be a good idea. Having it only delete files generated by cargo is in general rather difficult due to the existence of build scripts that may make their own files and folders in the target directory.
Honestly, I've been programming for 40 years. I do not invoke random scripts and I would never have issued a command like that. Cargo did something that it should not have done, whether based on instructions in a referenced package or otherwise.
Actually, the package system is another major concern with rust. It would be impossible to review all of the code in a package like serde before using it, and a real project would need several libraries that could have dozens or even hundreds of dependencies (I referenced a couple of libraries and my project built 250+ artifacts). JSON support is standard in frameworks such as .NET, but depends on third parties in rust. I am not sure that this is an optimal situation for core infrastructure, especially when things that developers consider core can cause serious problems, such as this one with /tmp. Rust claims to be a secure language, but the toolchain is far from secure, which may be a bigger risk than poor coding practices, especially as all of those details are disclosed in public.
Also, I think cargo should build to a subdirectory of that setting, using a unique directory name each time, possibly copying artifacts from a prior build before optionally deleting that prior build, partially to avoid issues such as this but also so that there can be a record of builds, and only delete subdirectories of that setting that match a cargo naming convention, or contain a specific file, or something.
I can't tell you how the /tmp option got into your config file, but it is not a standard configuration option. Whether having a small standard library is a good idea is a different discussion, and I don't feel like having it again right now.
I understand avoiding the discussion, and I don't mean to begin it here either, but it is related. I was concerned about the small library at first, but thought that the approach could have merits until I started trying to use libraries. Now I want rust with .NET libraries.
I appreciate your input, and I recognize that you are trying to help, but it also feels like "blame the user", when I don't feel that I am reasonably to blame. Please understand that my context in this discussion is also a bit frustrated, as I have been evangelizing for rust and now have concerns about using it for anything significant. I feel like I should report this as an issue to the tool maintainers, but somehow I don't think it would be taken seriously, as I think the issues are much bigger than this setting issue that has a (post-potential-catastrophe) simple workaround.
The bigger issue is that these tools could install anything, change anything, delete anything, curl anything including scripts and even Linux and Windows binaries to invoke, send my source code anywhere, update my login scripts, or anything else that my account can do, all without my knowledge (if they can run scripts, they can /dev/null stderr, so I would not have seen the warning message). Maybe I need a Linux account with minimal permissions to run cargo? Using a package is basically like downloading random software from the Internets?
I am curious but also afraid to find out what might happen if I ran the same cargo processes under Windows, where I actually do use C:\temp. I cannot find the relevant config file under Windows, which requires special effort to invoke Unix shell scripts and does not have a /tmp. So Windows may have a default build directory not specified in config, such as within the project directory, as a developer would expect. Linux may have the same default.
I'm sorry for blaming you, but I just don't see any other way that the config option would end up there.
I think you would be taken seriously if you suggested something like emitting an error when the build directory has some bad value, for some reasonable definition of bad. As for other suggestions, it depends on the suggestion. There are many languages whose ecosystem you could make similar complaints against, yet it is widely considered acceptable.
I was trying to build an http client and server. I remember the actix stuff, plus surf and another http client. The problem may be with any of the hundreds of things that they referenced. I do not have a record of the .toml edits.
Unfortunately, when I changed it. I had done ls -ltr but unfortunately cleared the console before that edit. I'm sorry. I think the backup has the datestamp of the copy operation rather than the original touch date of the file. I am certain that I had never touched this file previously.
I'm sorry, I don't really have the skills or the time to follow the toml paths. I have not heard of build.rs and I do not see it anywhere. I tried two projects to implement HTTP client and server. I do not remember exactly which libraries I tried - serde, surf, actix, tokio, http, and another HTTP client, most likely hyper, and possibly another HTTP server. I was just experimenting, so nothing went into git. Archives of the current projects here (one has credentials, but they don't work, are not important, do not allow write access, and can be easily changed on the server if a DOS comes in):