On Wed, 12 Feb 2025 at 17:31:40 +0000, Ian Jackson wrote:
> * Decide that it is the job of a virt server to provide $HOME,
> and that for the schroot virt server it is the job of whatever
> creates the chroot. Patch sbuild-createchroot's sbuild profile
> to provide a dummy, writeable, empty, $HOME.
I don't think sbuild-createchroot is aware of schroot profiles - it exists
at a lower level - and all standard schroot profiles share the real
nss databases (includng /etc/passwd) with the chroot anyway, overwriting
whatever sbuild-createchroot might have provided.
buildds, in particular, intentionally do not provide a valid home
directory (the buildd user's home directory is /nonexistent) because at
some point in the past it was thought to be essential that we detect
packages that access $HOME during build, and enforce them failing to
build (so that requiring access to $HOME during build is a "worse than
RC" bug that simply cannot exist in buildd-built packages, because as
a project we prefer to make those packages unable to be built).
Newer versions of debhelper provide a writeable temporary $HOME that is
not the real home directory, turning this class of bugs into non-bugs.
If a contributor feels that it's inappropriate for manual builds that
are not mediated by dpkg-buildpackage to write caches in $HOME, they can
still send a bug report if appropriate, but it isn't really sbuild's or
dpkg's job to police this.
Packages that rely on being able to access the home directory according
to the system user database in /etc/passwd or equivalent (not necessarily
the same as $HOME) will usually still fail to build. For example, if an
authentication protocol involves looking in the user's "official" home
directory for something analogous to ~user/.ssh/authorized_keys, we can
still expect unit tests for that protocol to fail (if they are not
special-cased to use $HOME in the case where the authenticating user
is equal to the current user), because they will be unable to access
/nonexistent/.ssh/authorized_keys.
> * Decide that virt servers are allowed to not provide $HOME.
> Have the autopkgtest virt core check to see if some home directory
> exists, and "polyfill" it by using something near $AUTOPKGTEST_TMP.
> (Not *within* $AUTOPKGTEST_TMP because that namespace belongs to
> the test, not to autopkgtest.)
autopkgtest cannot seamlessly "polyfill" this unless it is able to edit
/etc/passwd to reflect this home directory, because, as mentioned above,
some packages care about the "official" home directory from the user
database.
> ISTM that this is probably the best option if we suspect that other
> virt providers might also end up using images without a useful $HOME.
Historically, most of the other virt providers have created a test user
(canonically named "user") with a valid home directory for which $HOME
and the user database agree, and returned it as the suggested-normal-user.
In virt providers with the revert-full-system capability (which is all
of them except null, chroot, schroot and sometimes ssh), recent versions
of autopkgtest will automatically create an unprivileged user at runtime,
with a valid home directory, if there is no suggested-normal-user. At some
point someone should probably go through all the autopkgtest-build-foo
helpers and make them stop creating a normal user, leaving autopkgtest
to do that at runtime. I'll add it to my list of work to feel guilty
about not having done.
The fact that schroot cannot safely do this (because it shares the real
$HOME under at least some circumstances) is one of the reasons that I
prefer to use and recommend other virt providers for automated package
testing.
smcv
