Bug#989547: fai-client: ROOTCMD relies on specific unshare features
* Thomas Lange [Sun Jun 20, 2021 at 01:39:47AM +0200]: > The Recommends was added because fdisk was added as a new separate package. > We need this from buster on. > But there's no need to define a dependency to util-linux, because > it's a required package. JFTR[1]: But you're depending on a specific behavior and version (>=2.32-0.1~) of the package. A versioned depends is perfectly fine for this (see e.g. https://lintian.debian.org/tags/build-depends-on-essential-package-without-using-version). > Since FAI 5.10 is not part of stretch, I see no major impact that we > call unshare with options not available in this distribution. JFTR[1]: FAI indeed isn't part of official stretch, but as you know we still[2] have packages at https://jenkins.grml.org/job/fai-binaries/ and those are known to indeed be running also on Debian/stretch systems (that's why I stumbled upon this issue). Also if someone is backporting FAI (either officially or just privately), such a missing dependency will only be noticed via runtime failures later on. > It would be nice if FAI would atomatically detect if it is run in an > unprivileged container. Even if it would be able to detect this (see my other mail), the unshare command line as present won't work with systems running Debian/stretch. [1] *But* I agree, that when $ROOTCMD can be controlled from outside, there's no need for a versioned util-linux dependency (which would actually prevent usage of FAI on Debian/stretch then!). [2] I noticed that you are no longer triggering my service, not sure yet though whether that's a problem on your or my side :) regards -mika- signature.asc Description: Digital signature
Bug#989547: fai-client: ROOTCMD relies on specific unshare features
Package: fai-client Severity: normal The Recommends was added because fdisk was added as a new separate package. We need this from buster on. But there's no need to define a dependency to util-linux, because it's a required package. Since FAI 5.10 is not part of stretch, I see no major impact that we call unshare with options not available in this distribution. And we alread have a workaround. It would be nice if FAI would atomatically detect if it is run in an unprivileged container. -- viele Grüße Thomas
Bug#989547: fai-client: ROOTCMD relies on specific unshare features
> On Mon, 07 Jun 2021 11:12:55 +0200, Michael Prokop said: > and provide an option to either use the old setting > (ROOTCMD="chroot $FAI_ROOT") or allow manually configuring it. A quick workaround is to redefine ROOTMD in a hook (ending in .sh) or in a file class/*.var. I wonder if a clean solution would be to detect if FAI is running in a docker or other container enironment and then set ROOTCMD without unshare. Does any know a reliable way to detect all container environments? -- viele Grüße Thomas
Bug#989547: fai-client: ROOTCMD relies on specific unshare features
Package: fai-client Version: 5.10.3 Severity: important Starting with FAI v5.10, it uses: ROOTCMD="unshare --pid --fork --kill-child --mount-proc chroot $FAI_ROOT" Though fai-client only recommends: Recommends: libgraph-perl, fdisk | util-linux (<< 2.29.2-3~) unshare(1) on e.g. Debian/stretch doesn't know the --kill-child option yet though. So it actually "Depends: util-linux >=2.32-0.1~" (the first Debian package version that shipped support for the --kill-child option). Furthermore this ROOTCMD setting with unshare fails in e.g. unprivileged docker containers: | root@f6c0db65ee69:/code/# unshare --pid --fork --kill-child --mount-proc chroot / ls | unshare: unshare failed: Operation not permitted It would be nice, if ROOTCMD isn't assumed to always work as such, and provide an option to either use the old setting (ROOTCMD="chroot $FAI_ROOT") or allow manually configuring it. regards -mika-
