[bug#53912] [PATCH 0/5] WIP Add WSL support.

[Jacob MacDonald <jaccarmac@gmail.com>]

Stefan wrote:

> The problems with sudo etc. in /run/setuid-programs/ stem from the nosuid and noexec flags, which WSL sets when mounting /run as tmpfs.

Do you know if there was a 5.10->5.15 change on that front? I only saw
the issue after upgrading WSL (and not Guix), even though I had to
work around several mount issues getting Guix set up in the first
place.

> This all seems to be far from perfect to me.

It is less than ideal.

> All in all WSL assumes the Filesystem Hierarchie Standard and /etc/environment

I do have some workarounds for the issues you mention; No long
examples since that work machine is airgapped, but I'll outline my
setup and can follow up with code. The filesystem standard, Linux and
Guix internals are the areas I'm fuzzy on, relying mostly on
third-party advice and a little bit of common-sense tinkering. It's
possible that something other than the WSL upgrade broke /run, but my
image started with a broken Guix and has undergone several successful
revisions.

> I use a guile script which remounts /run with these flags removed.

> With Windows 11 there is a boot option for the /etc/wsl.config, which might be the optimal place for a script to do re-mounts and start shepherd.

That is exactly right based on my experience. My init script doesn't
do any mounts (since the old WSL seemed to let me call sudo just
fine), but it does start as root and make sure the file system is sane
before kicking things off.

> Changing the default user to prevent problems with local drives seems possible with an /etc/wsl.conf file. But then it will not be possible to use root’s shell entry for the script anymore.

I never investigated the ownership of /mnt/c/, but it seemed to work
OK in userspace. I could create files or delete/trash them from a
user-level Emacs.

> Hm, I guess that even if the sudo problem is solved, then still a “sudo -i” won’t be possible with the patch. Is that right?

I haven't used this patch, so I'm not sure how it interacts. However,
/run/setuid-programs/sudo -i fails for me as expected while
/run/current-system/profile/bin/sudo -i works.

> [WSL] makes it hard to launch arbitrary commands as intended with just “wsl -e ls” in Guix. In such a case no shell is involved and no /etc/profile or ~/.profile is sourced, so ls won’t be found.

> Another possible problem with the patch might be the current-directory. I guess that a “wsl -d guix -e ls” will not list the directory from which the wsl command got invoked, but the user’s home directory.

This may be another Win11 feature, but I figured out that --shell-type
is a way around that annoyance. wsl --shell-type login ls in a fresh
PowerShell shows me files in my Windows home. My shell configuration
is small enough that the startup overhead is minimal, and based on
running top that way, there's no shell process that sticks around.

> With the WSL version I’m using on Windows 10 its /init requires a group cache for nscd, too.

The advice I saw on Guix-in-WSL suggested disabling nscd and I found
that to be the case.

> My setup is using a gnu.bat file, which invokes a guile script named gnu.scm in WSL, which – if needed – does the re-mounts and starts shepherd, and calls sudo to login the user and change the directory before executing further commands from the user. It is retaining some environment variables like TERM, and the content of WSLENV. So from the Windows side it is possible to call “gnu.bat ls -lA” etc. or just “gnu.bat” to get a shell.

My /etc/wsl.conf sets the default user and specifies a script to run
at boot. That script sets up /run/current-system, boots from it, and
does those few trivial fs sanity checks. From there, I can start new
shells for my user and everything seems to behave. System
reconfigurations were the biggest footgun prior to this latest
breakage, but this is my only GuixSD experience so that might be a
general problem.

Thanks!

Jacob.