Re: [PATCH RFC] util: pick a better runtime directory when XDG_RUNTIME_DIR isn't set
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...
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|