RFC: Implement a sandbox for environment variables and files

[jsgf]

Allow rustc to be invoked with constraints on which environment variables may
be queried, and which files may be included.

Rendered

Companion PR: rust-lang/rust#49387

[fbstj]

what's the benefit of this (rustc --env-set NAME=value) over NAME=value rustc --env-allow NAME other than brevity? is it specifically to stop propagation into sub-processes?

[jsgf]

Several reasons:

• You can use it to override the value of things that rustc (or the linker) itself uses, like PATH or LD_LIBRARY_PATH (among others)
• You can just change rustc's command-line args, whereas manipulating the environment might need deeper changes to whatever's invoking rustc (possibly system-dependent changes)
• Non-propagation isn't something that had occurred to me, but it is related to my first point

[fbstj]

my question was more that my understanding is that running > NAME=value rustc --env-allow NAME is only overriding the value for that instantiation of rustc, so I don't understand what your first point is specifying? are you meaning that some point before/around your 'sandboxed' area is able to access the environment but then the majority is going to use the --env-allow value?

your option may also be more sensible for any shells/clients which don't support 'instantiation-local environment variables', but I think the RFC could do with more discussion of these points.

thanks!

[jsgf]

I mean that when rustc itself is - say - invoking the linker, it may use $PATH to find the executable. If we want env!("PATH") to work at all, but not necessarily return the PATH that's been set up for rustc to be able to find its linker, then we need some way of allowing env!("PATH") and rustc's own runtime call to std::env::var("PATH") to be able to return distinct values.

[fbstj]

nit: capitalised rustc

[sfackler]

rust-lang/cargo#3676 is sort of related.

[jsgf]

@sfackler There seems to be a few use-cases in controlling the environment visible to build scripts.

[nikomatsakis]

cc @rust-lang/dev-tools -- I'm never sure who owns this sort of thing, but it's not clearly T-compiler. =)

[Centril]

@nikomatsakis so my reasoning for T-compiler was: "well, it makes changes to rustc" but that's not the best argument ever =P

[Manishearth]

I think it's fine under devtools.

(I also like this RFC and do think we (the devtools team) should eventually think about sandboxing build processes in general)

[est31]

I also like this RFC and do think we (the devtools team) should eventually think about sandboxing build processes in general

ohhh that would be awesome ❤️ ❤️ ❤️

[nrc]

We discussed this in the Cargo meeting today. The RFC doesn't have much content related to Cargo, given the early conversation, we've re-assigned to dev-tools (and the compiler team).

@jsgf is this RFC still something that would be useful for you?

[jsgf]

@nrc Yes. My plan is to split this into two RFCs to handle environment and files separately, and probably focus on env first as it is more straightforward. It's on my TODO list, but pushing closer to the top.

[Manishearth]

@jsgf should we close this in the meantime?

[jsgf]

@Manishearth Yes, I suppose so.