Bug#1084133: mutter: FTBFS on armhf: Directory "/tmp/.X11-unix" is not writable

[Simon McVittie]

On Sat, 05 Oct 2024 at 17:35:46 +0200, Aurelien Jarno wrote:
> Everything is fine on the buildds side. Both arm64 and armhf chroots on
> the above buildds have an empty 1777 root:root /tmp directory.
...
> Chroots are created identically in schroot and unshare mode. /tmp is
> part of the chroot, and not shared with the host.

Thanks for confirming that. I'm not sure what's going on here, why armhf
and all the other architectures are behaving differently, or what other
uid would have had the opportunity to create /tmp/.X11-unix in a buildd
environment.

If other developers don't get there first, at some point I'll try
re-uploading mutter with some `ls -al ... || true` near the dh_auto_test
invocation and see whether that gives us any more clues about what is
happening.

I'm particularly confused by this appearing to be unique to armhf, because
mutter's packaging doesn't do anything special on armhf that isn't shared
with other architectures like amd64 and arm64, where the tests passed.
Also, previous uploads of mutter into experimental built successfully,
including 47.0-1 which should be functionally equivalent to the failing
version now in unstable, and several older builds on arm-conova-03 which
is one of the ones where it failed today; so perhaps there is some recent
change affecting this?

> > systemd's /usr/lib/tmpfiles.d/x11.conf only creates /tmp/.X11-unix during
> > boot (and not when systemd is installed into a running system). Possibly
> > this directory is sufficiently special that schroot and unshare ought
> > to ensure its presence as an empty directory with the correct permissions
> > during chroot setup, but that can be a separate feature request.
> 
> Well if you package needs that directory, why not create it before
> running the tests?

deban/rules could certainly pre-create it and hopefully we can at least
get better diagnostics that way, but it can't create the directory with
its canonical ownership, because the build doesn't run as uid 0. Only
the maintainer scripts of a build-dependency have the opportunity to
create it with canonical ownership, but unfortunately installing
x11-common and/or systemd is not enough to make this happen.

On the other architectures' buildds, I believe it gets created by the
mutter tests during testing. Nothing in the package's debian/rules
can create it owned by root:root, but creating it owned by the build
user seems to be fine in practice. Some X11 implementations - Xvfb,
if I remember correctly? - log a warning when it isn't root-owned,
but still work.

However, if some other component (?) has already created it owned by a
different user (?), then it isn't going to be possible for debian/rules
to recover from that or fix the permissions, because it won't have
the necessary access to do so. (Or, if it's been created owned by the
build user but with strange permissions, those permissions won't get
fixed unless mutter very specifically does so.)

> I don't think it's reasonable for sbuild to ensure random directories
> are available in the chroot.

For random directories that a package can definitely create with a
suitable owner and mode (possibly overriding their location with an
environment variable, like XDG_RUNTIME_DIR), sure, I agree; and for
directories that a build-dependency can create without doing a potentially
unsafe write into a world-writeable directory, in general I'd also agree.

/tmp/.X11-unix and related subdirectories of /tmp are unusual in that
it's part of the historical X11 API for them to be hard-coded to be a
subdirectory of a world-writeable directory, so it's riskier than usual
for mechanisms like tmpfiles.d to create it other than during boot, and
as a result (I assume), /usr/lib/tmpfiles.d/x11.conf has the "D!" mode
for it. This is unlike most tmpfiles-managed directories which are below
/run or /var and have mode "D", allowing them to be created by
systemd-tmpfiles as invoked by maintainer scripts during install.

> if you really believe this is the right place to fix that, please
> report it to the sbuild package instead

It's on my list. (Sorry, I have been busy with other things today.)

    smcv