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