Hi, * Thomas Lange [Mon Jun 21, 2021 at 04:12:51PM +0200]:
> Here's the info I got about detecting if FAI is run inside a docker > container: > Googling around, there are a few ways. > It looks like this could be the most consistent: > grep -E ":/docker/.+$" /proc/1/cgroup > ..which is looking for cgroups under a docker cgroup > It may be refined to: > grep -E ":/docker/[0-9a-f]+$" /proc/1/cgroup > ..but I can't say that for sure. > What do you think, does that sound reasonable ? This sadly isn't going to be as simple. First of all, there are different ways how to detect containers, more specifically also docker containers, which are one, but not the only one implementation of (OCI-based) containers. Docker containers provide a file /.dockerenv, and several tools are checking for this and relying on it, see https://codesearch.debian.net/search?q=%2F.dockerenv&literal=1 E.g. systemd provides systemd-detect-virt, though systemd and docker sadly don't play nicely with each other (docker not following https://systemd.io/CONTAINER_INTERFACE/, furthermore also see e.g. https://github.com/systemd/systemd/issues/15393). Also one can't really rely on having systemd present in the chroot. Looking into /proc/1/cgroup, and checking whether /init.scope is present is another way to detect containers, see https://codesearch.debian.net/search?q=%2Fproc%2F1%2Fcgroup&literal=1&perpkg=1 (But this isn't really solving the problem either, see below.) But docker is only one way how to execute OCI-based containers, e.g. when using podman you're running docker(-like) images/containers, but e.g. /.dockerenv doesn't exist there. Furthermore, you can't easily detect whether you're running in privileged mode or not, and only in *unprivileged* containers the unshare-ing fails (while privileged mode is a security concern and not really recommended). So IMO don't put too much work, effort and magic into detecting whether you're running in container or not (it shouldn't matter actually), but instead check, whether the expected feature set is available. The command line I quoted in my initial bug report does that: unshare --pid --fork --kill-child --mount-proc chroot / ls If that fails, you can't rely on the unshare command line for ROOTCMD. Then we could either a) fall back to the previous "ROOTCMD=chroot $FAI_ROOT" behavior, or b) abort and inform the user, that ROOTCMD needs to be set/defined by the user. regards -mika-
signature.asc
Description: Digital signature
