Hi, David Elsing <[email protected]> writes:
> Ludovic Courtès <[email protected]> writes: > >> But it’s unsatisfactory: I would hope the unprivileged daemon would >> allow us to address that shortcoming. > > Yes it does, as long as the needed syscalls are not restricted. I'm not > sure when this will change with Docker [1]. > >>> I don't think the isolated build environment is possible when >>> `unshare' is not allowed and the UID is not 0 (except by using >>> something like PRoot), right? >> >> What I meant is that there’s only one ‘unshare’ call, which is necessary >> from a security viewpoint but not from a functional viewpoint. Offering >> an option to skip it in contexts where the tradeoff is acceptable could >> help maybe? > > Ah sorry, I was conflating `unshare` and `clone`. The default Docker > seccomp profile [2] of course also blocks (among other flags) > CLONE_NEWUSER (0x10000000) for the `clone` syscall without > CAP_SYS_ADMIN, using SCMP_CMP_MASKED_EQ. This also leads to EPERM being > returned. Oh OK. > [1] https://github.com/moby/moby/issues/42441 > [2] https://github.com/moby/moby/blob/master/profiles/seccomp/default.json So hmm, it looks like in practice we’re left with no choice but to keep using ‘--disable-chroot’ in Docker? Do you happen to know what people running Docker-in-Docker (or similar) do? Thanks, Ludo’.
