Package: autopkgtest Version: 5.44 Severity: normal When using an expendable container or VM (one with revert-full-system), recent-ish autopkgtest versions automatically create a normal user to be used for testing. I think this is preferable to requiring each virtualization backend to implement a heuristic to guess at a pre-existing user in the container/VM image that would be suitable for this purpose, and in future I'd like to move towards relying on this for all backends that use an expendable testbed.
However, this mechanism as currently implemented does not work as intended if the testbed is extremely minimal, for example mmdebstrap --variant=apt. Specifically, it requires the useradd program, from the passwd package. This is in the same sort of territory as #1098646 [1] and autopkgtest!536 [2], where creation of testbeds for autopkgtest needs to make a trade-off between two competing factors: 1. make the testbed as minimal as possible, so that if some package foo requires a high-Priority package bar, but is missing the dependency, autopkgtest is able to exhibit the bug so that it can be reported; 2. but also make the testbed contain enough packages for autopkgtest to do its job in a reasonably efficient and reasonably normal way, without needing to reinvent all of Debian's wheels [1] https://bugs.debian.org/1098646 [2] https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/536 Steps to reproduce ------------------ To reproduce, create a minimal testbed: mmdebstrap --variant=apt sid | \ autopkgtest-build-podman --tarball=- --vendor=debian --release=sid and use it to test a package that does not have the needs-root restriction: autopkgtest hello -- podman localhost/autopkgtest/debian:sid Expected result --------------- Testing succeeds Actual result ------------- The create-normal-user script fails with "Neither adduser nor useradd is installed". This is not podman-specific: in principle this could be reproducible with any backend that does not guarantee to install the passwd package, and does not attempt to autodetect or create a suggested-normal-user. It is probably not reproducible with autopkgtest-virt-unshare, which always creates a suggested-normal-user named "unshare", and implicitly requires passwd for that purpose. Similarly it is not reproducible with images generated by autopkgtest-build-qemu, which always creates a user named 'user' (again implicitly assuming that passwd is installed). Workarounds ----------- Workaround (1): Use mmdebstrap --variant=minbase, which includes non-Essential Priority: required packages, notably passwd. In unstable at the time of writing this means adding the following packages: e2fsprogs, login, login.defs, mount, passwd, tzdata; plus debconf, libpam-modules{,-bin}, libpam-runtime and mawk which are formally non-Essential, but are transitively Essential. It is this version that is currently documented in autopkgtest-{build,virt}-podman. Workaround (2): Use mmdebstrap --variant=apt --include=passwd, which adds login.defs, passwd and some more shared libraries, but not mount or tzdata. Possible solutions ------------------ Possible solution (1): Install passwd as part of setup-commands/setup-testbed, and/or install it before running the create-normal-user script. Accept that we will be unable to exhibit some bugs of the form "package foo requires passwd but lacks Depends: passwd". This is the same tradeoff as the one we currently make by preinstalling dpkg-dev, eatmydata and other convenient packages in setup-commands/setup-testbed. Possible solution (2): Before running create-normal-user, detect whether passwd is installed. If not, install it before running create-normal-user, then purge it and do an apt autoremove afterwards. This adds avoidable complexity and will make test setup slower, but ensures that our testbed can be very minimal, allowing autopkgtest to detect more bugs in the package under test. Possible solution (3): Write code in create-normal-user to find an unused uid/gid pair, then append a normal user to /etc/passwd and /etc/group using only Essential programs (getent and echo), with no locking or other nice things (this is hopefully an acceptable limitation for a container or VM that we already know is disposable). This adds avoidable complexity and will make test setup slower, but ensures that our testbed can be very minimal, allowing autopkgtest to detect more bugs in the package under test. Non-solutions ------------- We cannot create the normal user and then revert the testbed before testing (similar in spirit to autopkgtest!536), because if we did that, the normal user would disappear when the testbed was reverted. smcv
