On 2017-09-23 19:59, Rich Freeman wrote: > A read-only container is a much simpler solution and generates the > same kinds of errors as the current sandbox approach, but likely with > fewer compatibility issues. I'm not really sure what tracing gets us > that containers don't, other than having to make sure you trap > everything and handle it. The kernel already handles attempts to > write to read-only files and so on.
> We could add an API to designate specific files/directories/etc as > read-write, and then portage would bind mount them as writable in the > container. I doubt bind mounts will scale as far as we'd need them for this approach, i.e. tons of bind mounts needed for complicated builds would cause issues. As has been mentioned before, a different way would be to write some sort of FUSE fs that can handle only allowing access to a specified set of files in a performant manner. Leveraged alongside namespaces/containers this would probably provide us what we need assuming an API of sorts could be written to perform the various request/deny/etc actions on the FUSE fs that we already use for sandboxing. Tim
