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

[Stefan]

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