Hi Tom, On Sat, 26 Jun 2021 at 14:46, Tom Rini <[email protected]> wrote: > > On Sat, Jun 26, 2021 at 12:29:56PM -0600, Simon Glass wrote: > > Hi Alper, > > > > On Mon, 21 Jun 2021 at 12:52, Alper Nebi Yasak <[email protected]> > > wrote: > > > > > > The filesystem test setup needs to prepare disk images for its tests, > > > with either guestmount or loop mounts. The former requires access to the > > > host fuse device (added in a previous patch), the latter requires access > > > to host loop devices. Both mounts also need additional privileges since > > > docker's default configuration prevents the containers from mounting > > > filesystems (for host security). > > > > > > Add any available loop devices to the container and try to add as few > > > privileges as possible to run these tests, which narrow down to adding > > > SYS_ADMIN capability and disabling apparmor confinement. However, this > > > much still seems to be insecure enough to let malicious container > > > processes escape as root on the host system [1]. > > > > > > [1] > > > https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ > > > > > > Since the mentioned tests are marked to run only on the sandbox board, > > > add these additional devices and privileges only when testing with that. > > > > > > An alternative to using mounts is modifying the filesystem tests to use > > > virt-make-fs (like some EFI tests do), but it fails to generate a > > > partitionless FAT filesystem image on Debian systems. Other more > > > feasible alternatives are using guestfish or directly using libguestfs > > > Python bindings to create and populate the images, but switching the > > > test setups to these is nontrivial and is left as future work. > > > > > > Signed-off-by: Alper Nebi Yasak <[email protected]> > > > --- > > > > > > (no changes since v2) > > > > > > Changes in v2: > > > - Always pass in /dev/fuse to Azure's docker run invocation. > > > - Remove "and some EFI tests" from comment (no longer applies to that > > > block of code). > > > > > > .azure-pipelines.yml | 16 +++++++++++++++- > > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > Shouldn't this be done in gitlab too? > > In GitLab we don't control how docker is launched, is the problem. > That's up to the admins and we sometimes do, sometimes don't have the > capabilities enabled. That probably means we should update the CI doc > and also email the various CI admins about updating things.
OK I see, well once we have the docs I can try it. Regards, Simon
