A Cargo.toml file in parent directory which you cannot delete prevents cargo from building anything

[cbeuw]

Problem

On a shared system, there is a directory (weirdly, but it could've been a file) named Cargo.toml under $HOME/... It is owned by root with 000 permission. As the parent directory still has r permission, a cargo project under $HOME cannot be built as cargo will detect the bad Cargo.toml, attempt to access it and then error out with permission denied.

A root user could put a Cargo.toml under / which acts a system-wide DoS against cargo for other users.

I know this recursive look up is expected behaviour, but it doesn't really play well with file permissions on shared systems. This is unlike .cargo/config.toml where each user can override the parent directory with a more specific one.

Steps

No response

Possible Solution(s)

Add a flag, say --workspace-lookup-depth=n, to prevent cargo from looking more than n levels up the file system

Notes

No response

Version

No response

[weihanglo]

Thanks for describing the scenario well!

This looks like effectively what rust-lang/rfcs#3279 tries to address. There are some open pull requests for it:

• Add safe.directories config #10736
• Add safe-directories. rustup#3005

They got stale for a while. Hope we can move them forward someday.

Going to close this in favor of things above. Thank you.

[epage]

A workaround would be to add the [workspace] table to the Cargo.toml

Something we might explore for rust-lang/rfcs#3424 is modifying package.workspace to support package.workspace = false to disable workspace lookup. I wonder if we would ever consider making package.workspace = false the default, requiring workspace members to set package.workspace = true.

[RalfJung]

Also maybe cargo should treat 'Cargo.toml is a directory or we have insufficient permissions' as 'Cargo.toml does not exist'?