A modest proposal in re systemd support, WSLg, and how to support the latter in the former

[cerebrate]

I'm posting this as a discussion because I'm not entirely sure where it would fit in terms of bugs and features, and that in itself could probably use a little discussion.

To summarize the status quo: WSLg creates the /tmp/.X11-unix directory and its contents to support X; WSL systemd support bind mounts over two files, tmp.conf and x11.conf under /lib/tmpfiles.d, with /dev/null character devices to prevent systemd-tmpfiles from removing WSLg's creation; and at least on my Debian distribution, the WSLg /tmp/.X11-unix isn't there anyway.

Things I have noticed in digging into - these observations being based on my system and contrary observations by others welcomed - the whys and wherefores here:

tmpfs and the disappearing X support

As far as I can tell, the disappearing /tmp/.X11-unix isn't actually systemd-tmpfiles; it's the mounting of /tmp automatically by systemd. Per API File Systems, various key file systems are automatically mounted early in systemd's boot process, including /tmp.

Looking at the generated tmp.mount unit:

[Unit]
Description=Temporary Directory (/tmp)
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%,nr_inodes=400k

[Install]
WantedBy=local-fs.target

It is indeed mounting a fresh, clean /tmp tmpfs, and in doing so, hiding the preexisting tmpfs that has WSLg's .X11-unix in it.

It would appear possible to prevent this from happening by doing to /etc/systemd/system/tmp.mount what's currently being done to those /lib/tmpfiles.d files, thus masking it and preventing systemd from mounting over /tmp, but this may have other consequences. I haven't tried it myself.

About those tmpfiles.d files...

Let's take a look at the original source for tmp.conf and x11.conf.

tmp.conf

# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d

Looking at these entries, I don't think the former file would interfere with WSLg anyway. These entries merely create /tmp and /var/tmp if they don't exist yet (which /tmp does thanks to the above mount), and assigns them root owner and group, and permissions 1777, which they have anyway. q is equivalent to d on non-btrfs filesystems, and d doesn't remove directories period. The only possibly dodgy item in there is the aging config that would clean up untouched files after 10 days, but per the source code, that wouldn't be a problem because systemd-tmpfiles doesn't touch sockets.

Also, masking this file does come with the problem that /var/tmp no longer gets cleaned, and while /tmp is a tmpfs that is made afresh with every boot, /var/tmp isn't as temp files placed there should survive a boot cycle. (See documentation here.) So arguably if WSL is going to mask this file, it should also provide a replacement that cleans /var/tmp.

(Even if it's only an issue for those of us with 30 day-plus WSL uptimes, which aren't exactly impossible.)

x11.conf

# Make sure these are created by default so that nobody else can
# or empty them at startup
D! /tmp/.X11-unix 1777 root root 10d
D! /tmp/.ICE-unix 1777 root root 10d
D! /tmp/.XIM-unix 1777 root root 10d
D! /tmp/.font-unix 1777 root root 10d

# Unlink the X11 lock files
r! /tmp/.X[0-9]*-lock

This one, on the other hand, could be problematic because D, contra d, sets up the listed directory to be removed by systemd-tmpfiles --remove, which is called during systemd boot, and would remove the WSLg /tmp/.X11-unix if it were there. On the other hand, (a) that directory is a mount point and a mount point which is in use can't be removed; and (b) it isn't there anyway, due to the /tmp mount issue above.

Apart from that, the only difference between what it would set and the WSLg /tmp/.X11-unix is that it sets the sticky bit on the directory, which while not terribly relevant under WSL would be good security practice under native Linux, and is harmless in effect. As is creating the other directories such that they can't be hijacked, although, again, not terribly relevant under WSL.

To confirm this, I note that having restored the contents of these files has created no problems for me, given that I already have to remount /tmp/.X11-unix anyway due to systemd's mounting of a fresh /tmp.

A modest proposal

Perhaps a simpler approach to supporting WSLg under systemd is to work with the existing features rather than around them. If systemd is allowed to do its default thing uninterrupted, it creates a perfectly satisfactory mount point for /tmp/.X11-unix just waiting to be used.

So, instead of bind-mounting /dev/null over those two config files, why not use the same technique to insert a unit to, in its turn, bind mount /mnt/wslg/.X11-unix over /tmp/.X11-unix, such as:

[Unit]
Description=WSLg Under Systemd Service
DefaultDependencies=no
After=systemd-tmpfiles-setup.service
Before=sysinit.target
ConditionPathExists=/tmp/.X11-unix
ConditionPathIsMountPoint=!/tmp/.X11-unix
ConditionPathExists=/mnt/wslg/.X11-unix

[Mount]
What=/mnt/wslg/.X11-unix
Where=/tmp/.X11-unix
Type=none
Options=bind,ro

[Install]
WantedBy=sysinit.target

Which seems to me to achieve the same intended end with fewer potential issues?

Just some thoughts I had while poking around; hope they may prove of interest. 😁

[cerebrate]

The whole tmpfiles.d section is rendered obsolete by 0.68.2, but everything else here remains true: tmp.mount mounts a clean tmpfs over /tmp, and it's that original (on-disk) /tmp that has /tmp/.X11-unix/X0 in it.

(As can be confirmed by unmounting it, but then you've got an on-disk /tmp with random foo missing.)