[libvirt-users] libvirtd vs XDG_RUNTIME_DIR

[sbaugh at catern.com]

Lars Kellogg-Stedman <lars at redhat.com>
writes:
> I ran into an odd problem today.  I wanted to share it here in the
> hopes of maybe saving someone else some lost time.
>
> When you run libvirtd as an unprivileged user (e.g., if you target
> qemu:///session from a non-root account), then libvirt will open a
> unix domain socket in one of two places:
>
> - If XDG_RUNTIME_DIR is defined, then inside
>   $XDG_RUNTIME_DIR/libvirt/libvirt-sock
>
> - If XDG_RUNTIME_DIR is *not* defined, then inside
>   $HOME/.cache/libvirt/libvirt-sock
>
> With a CentOS 7 system, at least, if you ssh directly into an
> account, XDG_RUNTIME_DIR is set.  But!  If you `su -` to the account
> from root, e.g:
>
>     # su - stack
>
> Then XDG_RUNTIME_DIR is *not* set.  The problem is a little subtle,
> because most operations you will perform will work just fine in both
> cases: you can query for defined but not active guests, storagep
> pools, volumes, and so forth without a problem and you'll get the same
> answer.
>
> The problem crops up when you start a guest, which results in a
> persistent libvirtd process.  Now, depending on how you got to your
> account, you will either (a) talk to the persistent process, and
> you'll be able to see the running guests, or (b) you'll end up
> spawning a new ephemeral libvirtd process listening in the *other*
> location, and you won't see anything, and you will wonder why there is
> a qemu process running for your guest but it's not showing up in
> "virsh list" and what the heck is going on here.
>
> I don't know if there's a good solution to this, but the failure mode
> is really non-obvious.
>
> Cheers,

I've run into the same problem, while trying to inspect the VM that
users have made using qemu:///session on a shared shell server.

I reached the conclusion that the ultimate problem was, as is suggested
elsewhere in this thread, with PAM, and how su does not register a new
session with PAM/logind/systemd. As far as I know, there is no widely
used way for an administrator to get a shell as some user, registered
with PAM, without first authenticating specifically as that user.
(There is machinectl shell, but that is pretty new, and also rather
inflexible.)

I solved this problem by writing a small Kerberos plugin to allow
administrator principals in our domain to authenticate as any Unix user;
then to use qemu:///session, they can simply ssh in. This also allows
administrators to use qemu+ssh://someuser@host/session on remote hosts.