While containers are leaky, they are far better than most other mechanisms.
One issue I found is that one crate I develop has a test for unreadable files. I have to detect root and say "well, I can't test this" because I have no idea how to make a file unreadable as root (in any portable enough way to warrant the extra complexity). It's the main impetus for this RFC, but I have other uses for it as well (detecting kernel feature support). Being root in the container makes it interesting to test some of these things.
Shameless plug: cargo cache has a verify subcommand that will read all the .crate archives from the registry cache and compare them to the actual sources in the src cache of cargos download cache and will notify if it finds additional files or missing or modified (differing sizes) in the directory where the crate sources are extracted.
Sure. This doesn't help Windows, BSD, or macOS though. AFAIK, they're all very different and tend to be process-wide things, so if test scheduling isā¦unfortunate, such changes could affect other tests non-deterministically. Checking getuid is sufficient for now, but means that CI is not actually testing one codepath. Even capability dropping seem excessive for the immediate use case (extra test-only dep, more C bindings, etc.).
.