Re: [libvirt-users] libvirtd vs XDG_RUNTIME_DIR
On Thu, Mar 10, 2016 at 12:37:31PM +0000, Daniel P. Berrange wrote:
On Wed, Mar 09, 2016 at 01:01:40PM -0500, Lars Kellogg-Stedman
wrote:
> 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.
IMHO this is a bug in the pam config. We really expect to see the
same environment setup no matter how you login text console vs su
vs ssh vs GDM. If that's not happening, its always going to cause
bad behaviour across many apps, not only libvirt.
Talking to Alexander Bokovoy (of FreeIPA, CCed) on IRC on this topic, he
says:
'su -' does initialize environment to start a shell
as a login shell. It clears out everything but TERM from the old
environment
and sets a new one. If your shell for $user does
not set XDG_RUNTIME_DIR, then that's the issue, not PAM
XDG_RUNTIME_DIR is set by pam_systemd after logind created a session
for that user, but only in the case if user who authenticated is the
same as the original user of the session
when you do 'su - $user' as root, you'd get this [error message is
manually wrapped for this email]:
su[9188]: pam_systemd(su-l:session): pam-systemd initializing
su[9188]: pam_systemd(su-l:session): Asking logind to create
session: uid=1792600000 pid=9188 service=su-l type=tty
class=user desktop= seat= vtnr=0 tty=pts/1 display= remote=no
remote_user=root remote_host=
su[9188]: pam_systemd(su-l:session): Cannot create session:
Already running in a session
[NOTE: you need to add 'debug' option to pam_systemd.so,
/etc/pam.d/system-auth]
`su -` isn't a best tool, specifically under systemd -- it may be
more efficient to use systemd tools to create sessions and
activate/switch them
--
/kashyap