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

[Stefan via Guix-patches via <guix-patches@gnu.org>]

Hi!

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

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

But there is another mount-problem. When WSL is using root as the default user, then the default mounts of local drives like /mnt/c/ use uid=0 and gid=0. This is problematic, when a script is changing the user with sudo. So my script is unmounting all local drives and mounting them again with /sbin/mount.drvfs of WSL with the uid and gid of that user and the metadata flag. By the way, I was not able to use the type drvfs with the mount command from Guix for this. But I didn’t try the type 9p for this yet, which it actually seems to be.

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.

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?

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.

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.

I’m experimenting with another script, which like busybox evaluates its name, and put symlinks to it in /usr/local/bin/, which is in the default WSL search path. That script invokes the mentioned gnu.scm script. With this it is possible to call e.g. “wsl -d guix -e ls -l” for the Windows user in USERNAME.

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

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.

All in all WSL assumes the Filesystem Hierarchie Standard and /etc/environment and 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. This all seems to be far from perfect to me.


Bye

Stefan