search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.3k stars 814 forks source link

mounting of /mnt/wslg as user runtime dir breaks all users except that with uid=1000 #9025

Open cerebrate opened 1 year ago

cerebrate commented 1 year ago

Version

WSL version: 0.70.0.0

WSL Version

Kernel Version

5.15.68.1-20221008-2-microsoft-custom-WSL2+

Distro Version

Debian sid

Other Software

No response

Repro Steps

  1. Start a WSL instance as the default user (created with uid 1000).
  2. ls -la /run/user
  3. ls -la /run/user/1000
  4. Note that the user and group ownership of the directory and its contents are that of said default user.
  5. Start a second session in the same WSL instance as a different user (for example, as root: wsl -u root).
  6. ls -la /run/user
  7. ls -la /run/user/<uid>, where uid is that of the user the second session was started as (0, in the case of root)
  8. Note that the user and group ownership of the directory and its contents are that of the default user, not the second session user.
  9. Repeat as many times as you like; observe that the same phenomenon occurs with non-root users.

Expected Behavior

The user runtime directory should have the user and group ownership of the user for whom it was created.

Actual Behavior

The user runtime directory always has user and group ownership by the default (uid=1000) user, regardless of for whom it is created.

This is obviously related to #8918, in that it's an issue caused by the automatic bind mounting of /mnt/wslg over the user runtime directory. However, in this case, it's doing this not only for uid 1000, which is compatible with the WSLg contents due to their common uid, but also for every other uid. In their cases, not only do systemd user sessions fail to start (detecting the incorrect ownership of the runtime directory, as per my bug arkane-systems/bottle-imp#21), but the other users will in many cases not be able to make use of the runtime directory due to permissions errors (incorrect ownership combined with the rwx------ permissions on /mnt/wslg).

(My suggestion would be to eliminate of this bind mount in all cases where the uid is not 1000. This does mean that WSL sessions started as other users will not have direct access to WSLg services, but this is the normal situation under native Linux and users still have the usual tools to manage that.

There are some issues caused by having this bind mount even when the uid is 1000 given that systemd expects to manage the user runtime directory, but those are covered in #8918.)

Diagnostic Logs

No response

cerebrate commented 1 year ago

As a note for this:

As part of other work I've been doing, I have tried overriding the user-runtime-dir@.service to run the attached script rather than the default /lib/systemd/systemd-user-runtime-dir. Essentially, it creates a per-user runtime directory in /run/user at the normal location, then uses overlayfs to mount that (read-write) directory over the /mnt/wslg/runtime-dir directory using the same location as its mount point.

This keeps anything the logged-in user does, including deleting the contents of the /run/user/uid directory, from affecting the /mnt/wslg/runtime-dir directory, and also makes the latter's contents available to other users without interference from the other contents of the runtime directory, as can be seen here with two users logged in:

image

image

As an approach that avoids many of the possible pitfalls of assuming the UID of the WSL default user matches that of the WSLg runtime user and of exposing the contents of the WSLg runtime directory to user error, I thought it might be worth bringing to y'all's attention.

Script:

https://github.com/arkane-systems/bottle-imp/blob/dev-1.1/othersrc/scripts/imp-user-runtime-dir.sh

cforce commented 1 year ago

As a note for this:

As part of other work I've been doing, I have tried overriding the user-runtime-dir@.service to run the attached script rather than the default /lib/systemd/systemd-user-runtime-dir. Essentially, it creates a per-user runtime directory in /run/user at the normal location, then uses overlayfs to mount that (read-write) directory over the /mnt/wslg/runtime-dir directory using the same location as its mount point.

This keeps anything the logged-in user does, including deleting the contents of the /run/user/uid directory, from affecting the /mnt/wslg/runtime-dir directory, and also makes the latter's contents available to other users without interference from the other contents of the runtime directory, as can be seen here with two users logged in:

image

image

As an approach that avoids many of the possible pitfalls of assuming the UID of the WSL default user matches that of the WSLg runtime user and of exposing the contents of the WSLg runtime directory to user error, I thought it might be worth bringing to y'all's attention.

Script:

https://github.com/arkane-systems/bottle-imp/blob/dev-1.1/othersrc/scripts/imp-user-runtime-dir.sh

Can you explain the parameters and give a hit why i get the error

sudo ~/scripts/fix_XDG_RUNTIME_DIR.sh start myuser
Failed to connect to system bus: No such file or directory
andremarianiello commented 11 months ago

Would be nice to see a fix for this as this affects me as well.

mfroment commented 7 months ago

@cerebrate Thanks to your great explanations, I've finally been able to figure out why a few things had been breaking on my end (my current WSL UID:GID being 1001:1001). It would be nice if this could be fixed in wsl/wslg.