cargo login should ensure ~/.cargo/config is not world-readable

[lilyball]

I have a preexisting ~/.cargo/config, which I created to define paths. When running cargo login, it happily added my token to that file even though it has the mode 0644. cargo login should either change the mode to 0600 and issue a warning telling me it did so, or it should do nothing and print an error telling me I need to fix the mode on the file.

[lilyball]

Note: it should probably complain about group-readable too, not just world-readable. And other cargo commands that use the token may want to validate that the file isn't group-readable or world-readable, and issue an error if so, telling me that I may want to consider resetting my API token.

[kmcallister]

+1. OpenSSH enforces this on private key files, we should do the same.

[carols10cents]

I started trying to look into fixing this, but I'm not sure how to do this in a cross-platform way given what I could find out about the state of implementing file permissions for Windows in the standard library.

The docs for Permissions currently say:

This module only currently provides one bit of information, readonly, which is exposed on all currently supported platforms. Unix-specific functionality, such as mode bits, is available through the os::unix::PermissionsExt trait.

... which sounds like not much is available for windows. Sooo I wasn't sure whether to try and fix this just for unix systems for now, orrrr if there's a crate that implements more granular permissions for windows that cargo would be willing to have as a dependency orrrr something else...?

Some more relevant discussions:

• Expand the scope of std::fs rfcs#939
• RFC: Expand the scope of std::fs rfcs#1044

[alexcrichton]

@carols10cents yeah to the best of my knowledge there's not a canonical "easy way" to make a file not-world-readable on Windows like there is on Unix. I think that an implementation of this for now would be fine just calling chmod directly (e.g. just using libc::chmod)

[nodakai]

Also, the entire ~/.cargo, in which cargo creates various files and directories, must be (in POSIX terminology) 0700 to avoid symlink race attack.

[matklad]

I think this is handled by #3978. Now we store credentials in a separate file with correct permissions.

If you think that this issue is not fixed, feel free to reopen!