Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
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 wrote: > On Wed, Nov 29, 2023, 20:59 Thomas Larsen Wessel > 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=ELCON45223PRIORITY=6SYSLOG_FACILITY=1MESSAGE=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 >> wrote: >> >>> On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel >>> 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@1000.service ExecStartPre: >>> >>> Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR: >>> WaitForBootProcess:3237: /sbin/init failed to start within 1 >>> 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@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?
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
On Wed, Nov 29, 2023, 20:59 Thomas Larsen Wessel 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=ELCON45223PRIORITY=6SYSLOG_FACILITY=1MESSAGE=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 > wrote: > >> On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel >> 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@1000.service ExecStartPre: >> >> Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR: >> WaitForBootProcess:3237: /sbin/init failed to start within 1 >> 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@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 >> 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
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
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=ELCON45223PRIORITY=6SYSLOG_FACILITY=1MESSAGE=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. On Mon, Nov 27, 2023 at 10:37 AM Andrei Borzenkov wrote: > On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel > 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@1000.service ExecStartPre: > > Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR: > WaitForBootProcess:3237: /sbin/init failed to start within 1 > 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@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 > 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 > >> > > >> >
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
On Mon, Nov 27, 2023 at 1:06 AM Thomas Larsen Wessel 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@1000.service ExecStartPre: Nov 27 12:34:22 tumbleweed unknown: WSL (2) ERROR: WaitForBootProcess:3237: /sbin/init failed to start within 1 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@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 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 >> > >>
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
On Mon, Nov 27, 2023 at 6:02 AM Thomas Larsen Wessel 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? 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. > In Ubuntu it is *likely* to be systemd invoked through PAM (not systemd as in init/pid1, but one of the additional components), but in general it is *not guaranteed* to be a systemd component (some Linux distributions use alternative PAM modules to do this). In a 100% systemd-based system, 1) pam_systemd requests systemd-logind to create a user session (your syslog line 1), 2) systemd-logind starts the user@ system system service; 3) as a dependency this also starts the user-runtime-dir@ system service; 4) the user-runtime-dir@ service creates the runtime directory for you. In older versions it was slightly different; logind did it internally. -- Mantas Mikulėnas
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
> > 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? 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 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 > > > >
Re: [systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
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
[systemd-devel] WSL Ubuntu creates XDG_RUNTIME_DIR with incorrect permissions
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? 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
