| 1 |
On Sat, Sep 23, 2017 at 7:42 PM, Alec Warner <antarus@g.o> wrote: |
| 2 |
> |
| 3 |
> We could try forcing failures (say, by not having / mounted as lowerdir, so |
| 4 |
> syscalls against the rootfs would just fail as E_NOENT) but then we are |
| 5 |
> still stuck with the tricky part; which is that sometimes things *do* need |
| 6 |
> to read / write from the rootfs and the sandbox add* API is available to do |
| 7 |
> that. How would we implement something like that here? |
| 8 |
> |
| 9 |
|
| 10 |
I would personally recommend against the overlay approach for all the |
| 11 |
reasons you state. |
| 12 |
|
| 13 |
A read-only container is a much simpler solution and generates the |
| 14 |
same kinds of errors as the current sandbox approach, but likely with |
| 15 |
fewer compatibility issues. I'm not really sure what tracing gets us |
| 16 |
that containers don't, other than having to make sure you trap |
| 17 |
everything and handle it. The kernel already handles attempts to |
| 18 |
write to read-only files and so on. |
| 19 |
|
| 20 |
We could add an API to designate specific files/directories/etc as |
| 21 |
read-write, and then portage would bind mount them as writable in the |
| 22 |
container. |
| 23 |
|
| 24 |
-- |
| 25 |
Rich |
Archives