On Mon, Feb 12, 2024 at 2:35 PM Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2024-02-12 08:16, Martin Jambor wrote: > >> This probably ties in somewhat with an idea David Malcolm had riffed on > >> with me earlier, of caching files for diagnostics. If we could unify > >> file accesses somehow, we could make this happen, i.e. open/read files > >> as root and then do all execution as non-root. > >> > >> Sandboxing will have similar requirements, i.e. map in input files and > >> an output file handle upfront and then unshare() into a sandbox to do > >> the actual compilation. This will make sure that at least the > >> processing of inputs does not affect the system on which the compilation > >> is being run. > > > > Right. As we often just download some (sometimes large) pre-processed > > source from Bugzilla and then happily run GCC on it on our computers, > > this feature might be actually useful for us (still, we'd probably need > > a more concrete description of what we want, would e.g. using "-wrapper > > gdb,--args" work in such a sandbox?). I agree that for some even > > semi-complex builds, a more general sandboxing solution is probably > > better. > > Joseph seems to be leaning towards nudging people to a general > sandboxing solution too. The question then is whether this takes the > shape of a utility in, e.g. contrib that builds such a sandbox or simply > a wiki page.
GCC driver support is then to the extent identifying the inputs and the outputs. I'm not sure a generic utility can achieve this unless the outputs need to be retrieved from somewhere else (not "usual" place when invoking un-sandboxed). Even the driver doesn't necessarily know all files read/written. So I suppose better defining of the actual goal is in order. > gcc -sandboxed -O2 -c t.ii -fdump-tree-all what should this do? IMO invoked tools (gas, cc1plus) should be restricted to access the input files. Ideally the dumps would appear where they appear when not sandboxed but clearly overwriting existing files would be problematic, writing new files not so much, but only to the standard (or specified) auxiliary output file paths. Richard. > Thanks, > Sid
