Lars Kellogg-Stedman <lars@xxxxxxxxxx> 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. _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
