On 2/18/25 12:21 PM, Daniel P. Berrangé wrote:
On Tue, Feb 18, 2025 at 02:50:52PM +0000, Daniel P. Berrangé wrote:
On Tue, Feb 18, 2025 at 09:33:43AM -0500, Laine Stump wrote:
On 2/18/25 4:26 AM, Daniel P. Berrangé wrote:
On Mon, Feb 17, 2025 at 03:11:56PM -0500, Laine Stump wrote:
On 2/17/25 5:28 AM, Daniel P. Berrangé wrote:
On Mon, Feb 17, 2025 at 02:14:49AM -0500, Laine Stump wrote: > But sometimes XDG_RUNTIME_DIR isn't set in the user's environment.
Do you have examples of scenarios in which this happens, and yet the /run/user/NNNN directory is still being created, as that rather sounds like something is broken outside of libvirt.
After seeing the bug report, I replicated the situation by ssh'ing in as a user that hadn't previously logged in, and then unsetting XDG_RUNTIME_DIR. I hadn't thought there might be some other case where the user could be logged in but XDG_RUNTIME_DIR had never been set.
But after seeing your question I tried running
sudo $someuser virsh list
NB, that is the classic sudo usage trapdoor, because they didn't make "-i" (aka --login) the default, so your environment is not populated correctly.
I'd hope that when passing sudo -i ... it will do the right thing
It seems not. If I login as $someuser, start a guest, then in a separate terminal window from root run:
sudo -u $someuser -i virsh list
It returns an empty list (the same as if I omit the -i). By running the same command without "virsh list", I'm given a shell instance, and within that shell I can see that $UID, $USER, and $EUID are all set, but $XDG_RUNTIME_DIR is not.
Hmm, this appears to be caused by systemd_pam
When using "su -" (similar seen with sudo)
su[5870]: pam_systemd(su-l:session): pam-systemd initializing su[5870]: pam_systemd(su-l:session): New sd-bus connection (system-bus-pam-systemd-5870) opened. su[5870]: pam_systemd(su-l:session): Asking logind to create session: uid=1001 pid=5870 service=su-l type=tty class=user desktop= seat= vtnr=0 tty=pts/3 display= remote=no remote_user=root remote_host= su[5870]: pam_systemd(su-l:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a su[5870]: pam_systemd(su-l:session): Not creating session: Already running in a session or user slice su[5870]: pam_systemd(su-l:session): pam-systemd shutting down
vs used with ssh:
sshd-session[5937]: pam_systemd(sshd:session): pam-systemd initializing sshd-session[5937]: pam_systemd(sshd:session): New sd-bus connection (system-bus-pam-systemd-5937) opened. sshd-session[5937]: pam_systemd(sshd:session): Asking logind to create session: uid=0 pid=5937 service=sshd type=tty class=user desktop= seat= vtnr=0 tty= display= remote=yes remote_user= remote_host=10.42.28.158 sshd-session[5937]: pam_systemd(sshd:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a sshd-session[5937]: pam_systemd(sshd:session): Reply from logind: id=12 object_path=/org/freedesktop/login1/session/_312 runtime_path=/run/user/0 session_fd=9 seat= vtnr=0 original_uid=0
So if the current user is already in a login sesssion, it'll refuse to start a new session.
I struggle to understand the rationale for this behaviour. It seems guaranteed to break stuff...
Apparently, 'su -' and 'sudo' shouldn't be used anymore if you want a shell running as a different user which can run arbitrary apps. Instead you're expected to use
machinectl shell username@
Or
sudo machinectl shell username@
which will get the full set of env info setup.
I find it somewhat dubious to simply re-declare that decades of usage of 'su' and 'sudo' is now wrong but that's the documented answer:
https://github.com/systemd/systemd/issues/7451#issuecomment-346787237
Likewise in context of RHEL:
https://access.redhat.com/solutions/6634751
Anyway, given that this is deliberate behaviour, I'm not convinced that it is libvirt's job to workaround, even if we think that behaviour is sub-optimal.
Especially since my workaround ends up being a "breakaround" if /run/user/$OTHER_UID doesn't already exist (i.e. if there isn't already a user session created for that user in some other way - we try to create /run/user/$OTHER_UID/libvirt, and fail), I definitely agree. Rich suggested online last week that maybe we could log a warning if XDG_RUNTIME_DIR hasn't been set in the environment (thus indicating that we're being executed via "sudo -u $user" or similar). I made an example patch of that and am sending it as an RFC so that anyone who wants can try it out and see if it's useful (and also suggest a better warning message, maybe pointing to a knowledgebase article with more details).