[libvirt-users] libvirtd vs XDG_RUNTIME_DIR

[Kashyap Chamarthy]

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