[systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions

Sun Dec 10 10:37:51 UTC 2023

Thank you for your elaborate explanations, both of you :) My late response
is only because it has taken some time for me to poke around in systemd and
other relevant parts of Linux, to get a better understanding.

I have now created an issue: https://github.com/microsoft/WSL/issues/10896,
where I think it belongs.

The validate_runtime_directory in pam_systemd already does a number of
checks on XDG_RUNTIME_DIR. To me it seems appropriate if it also verified
the permissions to be 700. Do you agree? That would cause a warning (which
is a help to the developers) when something/someone violates the
specifications.

On Wed, Nov 29, 2023 at 10:51 PM Mantas Mikulėnas <grawity at gmail.com> wrote:

> On Wed, Nov 29, 2023, 20:59 Thomas Larsen Wessel <mrvelle at gmail.com>
> wrote:
>
>> Thanks both of you! :)
>>
>> I have taken some time to digest your answers. And in particular I have
>> tried to investigate this line closer:
>>
>> *Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for
>> andrei*
>>
>> I have found the equivalent log line on my WSL Ubuntu. I was hoping I
>> could find out more about where its coming from; ie which process / service
>> prints this. But journalctl does not tell me much about the origin.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *journalctl -b --grep "Creating login session for velle" -o verboseWed
>> 2023-11-29 18:41:19.982271 CET
>> [s=d318bdab5d1f4ad7a48a947e6fff4a01;i=2d53;b=c8682ff139cf40da8326fd63d7c34d7c;m=1649>
>>   _TRANSPORT=kernel    _MACHINE_ID=967980c77d4743298ceaeb5d512bf388
>> _HOSTNAME=ELCON45223    PRIORITY=6    SYSLOG_FACILITY=1    MESSAGE=WSL (2):
>> Creating login session for velle
>> _BOOT_ID=c8682ff139cf40da8326fd63d7c34d7c
>> _SOURCE_MONOTONIC_TIMESTAMP=23368229*
>>
>> Most log entries in journalctl has a _PID field, but some don't, and this
>> one does not. Why? What does it tell, that a log entry has no _PID? As far
>> as I know ever process has an PID, even systemd itself has a PID (which is
>> always 1). Or am I wrong about that? I see now reason why those PIDs are
>> not saved together with the log entries.
>>
>
> According to _TRANSPORT the message went through the kernel log (dmesg),
> i.e. it was either kernel-generated (no PID) or it was written by the
> process to /dev/kmsg (PID information not preserved) rather than being sent
> the usual way through syslog. There might have been a PID but journald had
> no way to obtain it.
>
> That aside, another thing about WSL2 is that the entire VM actually boots
> a "system distro" first and the user-facing Ubuntu distro is started as a
> container. So there are several processes that run within the VM but exist
> outside of the container's PID namespace and therefore don't have PIDs from
> the Ubuntu container's PoV; only the "host" namespace has PIDs for them.
>
> (Consider how a container's "PID 1" looks from outside the container...)
>
>
>
>>
>>
>> On Mon, Nov 27, 2023 at 10:37 AM Andrei Borzenkov <arvidjaar at gmail.com>
>> wrote:
>>
>>> On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel <mrvelle at gmail.com>
>>> wrote:
>>> >>
>>> >> WSL does not use systemd by default.
>>> >
>>> >
>>> > According to this article, it systemd has been default on WSL Ubuntu
>>> since june 2023. https://learn.microsoft.com/en-us/windows/wsl/systemd
>>> >
>>> > "Systemd is now the default for the current version of Ubuntu that
>>> will be installed using the wsl --install command default."
>>> >
>>> > Also when I look in the /var/log/auth.log, there are many lines with
>>> systemd, e.g.:
>>> >
>>> > Nov 25 22:30:14 ELCON45223 systemd-logind[155]: New session 6 of user
>>> velle.
>>> > Nov 25 22:30:14 ELCON45223 systemd: pam_unix(systemd-user:session):
>>> session opened for user velle(uid=1000) by (uid=0)
>>> >
>>> > Could someone please help me understand exactly which part creates
>>> this XDG_RUNTIME_DIR folder?
>>>
>>> /run/user/$UID for the "console" session (the one you get when
>>> starting a WSL instance) is created by WSL before systemd. Adding "ls
>>> -l /run/user" to user-runtime-dir at 1000.service ExecStartPre:
>>>
>>> Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR:
>>> WaitForBootProcess:3237: /sbin/init failed to start within 10000
>>> Nov 27 12:34:22 tumbleweed unknown: ms
>>> Nov 27 12:34:22 tumbleweed unknown: WSL (2): Creating login session for
>>> andrei
>>> ...
>>> Nov 27 12:34:22 tumbleweed systemd[1]: Created slice User Slice of UID
>>> 1000.
>>> Nov 27 12:34:22 tumbleweed systemd[1]: Starting User Runtime Directory
>>> /run/user/1000...
>>> Nov 27 12:34:22 tumbleweed ls[520]: total 0
>>> Nov 27 12:34:22 tumbleweed ls[520]: drwxr-xr-x 4 andrei users 120 Nov
>>> 27 12:34 1000
>>> Nov 27 12:34:22 tumbleweed systemd-logind[160]: New session 11 of user
>>> andrei.
>>> Nov 27 12:34:22 tumbleweed systemd[1]: Finished User Runtime Directory
>>> /run/user/1000.
>>>
>>> So logind invokes user-runtime-dir at 1000.service, but it sees the
>>> existing directory and does nothing. I would suggest asking this
>>> question on WSL support channels.
>>>
>>> > Is it part of the systemd repo or not? And if the answer is (or may
>>> be) different between Ubuntu and WSL Ubuntu, I would be happy if you share
>>> what you know about any any of those cases :) Right now, I barely know
>>> where to report this issue.
>>> >
>>> >
>>> > On Sun, Nov 26, 2023 at 10:07 AM Andrei Borzenkov <arvidjaar at gmail.com>
>>> wrote:
>>> >>
>>> >> On 26.11.2023 02:39, Thomas Larsen Wessel wrote:
>>> >> > I set up WSL on Windows 10 and created an instance from the default
>>> Ubuntu
>>> >> > 22.04 image.
>>> >> >
>>> >> > I ran some (non-GUI) software that somehow relies on Qt, and
>>> apparently Qt
>>> >> > does some checks on the XDG environment, so I got the following.
>>> >> >
>>> >> > *Warning: QStandardPaths: wrong permissions on runtime directory
>>> >> > /run/user/1000/, 0755 instead of 0700*
>>> >> >
>>> >> > And yes, all the user folders are set to 755, including much of
>>> their
>>> >> > content, which violates the XDG Base Directory Specification.
>>> (screenshot:
>>> >> > https://i.imgur.com/ISn3ebh.png).
>>> >> >
>>> >> > As far as I can understand, its some part of systemd, that creates
>>> this
>>> >> > folder. So is this an issue with systemd?
>>> >> >
>>> >>
>>> >> WSL does not use systemd by default.
>>> >>
>>> >> > The validate_runtime_directory in pam_systemd already does a number
>>> of
>>> >> > checks on XDG_RUNTIME_DIR. How about also checking if the
>>> permissions are
>>> >> > correct/valid?
>>> >> >
>>> >> > Sincerely, Thomas
>>> >> >
>>> >>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20231210/addc362f/attachment.htm>