======

I'm sending this as an RFC just because what it's doing feels kind of
dirty - directly examining XDG_RUNTIME_DIR seems like an "end run"
around the Glib API. If anyone has a better idea of what to do, please
give details :-)

======

When running unprivileged (i.e. not as root, but as a regular user),
libvirt calls g_get_user_runtime_dir() (from Glib) to get the name of
a directory where status files can be saved. This is a directory that
is 1) writeable by the current user, and 2) will remain there until
the host reboots, but then 3) be erased after the reboot. This is used
for pidfiles, sockets created to communicate between processes, status
XML of active domains, etc.

Normally g_get_user_runtime_dir() returns the setting of
XDG_RUNTIME_DIR in the user's environment; usually this is set to
/run/user/${UID} (e.g. /run/user/1000) - that directory is created
when a user first logs in and is owned by the user, but is cleared out
when the system reboots (more specifically, this directory usually
resides in a tmpfs, and so disappears when that tmpfs is unmounted).

But sometimes XDG_RUNTIME_DIR isn't set in the user's environment. In
that case, g_get_user_runtime_dir() returns ${HOME}/.config
(e.g. /home/laine/.config). This directory fulfills the first 2
criteria above, but fails the 3rd. This isn't just some pedantic
complaint - libvirt actually depends on the directory being cleared
out during a reboot - otherwise it might think that stale status files
are indicating active guests when in fact the guests were shutdown
during the reboot).

In my opinion this behavior is a bug in Glib - see the requirements
for XDG_RUNTIME in the FreeDesktop documentation here:

   https://specifications.freedesktop.org/basedir-spec/latest/#variables

but they've documented the behavior as proper in the Glib docs for
g_get_user_runtime_dir(), and so likely will consider it not a bug.

Beyond that, aside from failing the "must be cleared out during a reboot"
requirement, use of $HOME/.cache in this way also disturbs SELinux,
which gives an AVC denial when libvirt (or passt) tries to create a
file or socket in that directory (the SELinux policy permits use of
/run/user/$UID, but not of $HOME/.config). We *could* add that to the
SELinux policy, but since the glib behavior doesn't

All of the above is a very long leadup to the functionality in this
patch: rather than blindly accepting the path returned from
g_get_user_runtime_dir(), we first check if XDG_RUNTIME_DIR is set; if
it isn't set then we look to see if /run/user/$UID exists and is
writable by this user, if so we use *that* as the directory for our
status files. Otherwise (both when XDG_RUNTIME_DIR is set, and when
/run/user/$UID isn't usable) we fallback to just using the path
returned by g_get_user_runtime_dir() - that isn't perfect, but it's
what we were doing before, so at least it's not any worse.

Resolves: https://issues.redhat.com/browse/RHEL-70222
Signed-off-by: Laine Stump <laine@redhat.com>
---
 src/util/virutil.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/src/util/virutil.c b/src/util/virutil.c
index 2abcb282fe..4c7f4b62bc 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -538,6 +538,28 @@ char *virGetUserRuntimeDirectory(void)
 #ifdef WIN32
     return g_strdup(g_get_user_runtime_dir());
 #else
+    /* tl;dr - if XDG_RUNTIME_DIR is set, use g_get_user_runtime_dir().
+     *         if not set, then see if /run/user/$UID works
+     *         if so, use that, else fallback to g_get_user_runtime_dir()
+     *
+     * this is done because the directory returned by
+     * g_get_user_runtime_dir() when XDG_RUNTIME_DIR isn't set is
+     * "suboptimal" (it's a location that is owned by the user, but
+     * isn't erased when the user completely logs out)
+     */
+
+    if (!getenv("XDG_RUNTIME_DIR")) {
+        g_autofree char *runtime_dir = NULL;
+        struct stat sb;
+
+        runtime_dir = g_strdup_printf("/run/user/%d", getuid());
+        if (virFileIsDir(runtime_dir) &&
+            (stat(runtime_dir, &sb) == 0) && (sb.st_mode & S_IWUSR)) {
+            return g_build_filename(runtime_dir, "libvirt", NULL);
+        }
+    }
+
+    /* either XDG_RUNTIME_DIR was set, or /run/usr/$UID wasn't writable */
     return g_build_filename(g_get_user_runtime_dir(), "libvirt", NULL);
 #endif
 }
-- 
2.47.1

On Mon, Feb 17, 2025 at 02:14:49AM -0500, Laine Stump wrote:
> ======
> 
> I'm sending this as an RFC just because what it's doing feels kind of
> dirty - directly examining XDG_RUNTIME_DIR seems like an "end run"
> around the Glib API. If anyone has a better idea of what to do, please
> give details :-)
> 
> ======
> 
> When running unprivileged (i.e. not as root, but as a regular user),
> libvirt calls g_get_user_runtime_dir() (from Glib) to get the name of
> a directory where status files can be saved. This is a directory that
> is 1) writeable by the current user, and 2) will remain there until
> the host reboots, but then 3) be erased after the reboot. This is used
> for pidfiles, sockets created to communicate between processes, status
> XML of active domains, etc.
> 
> Normally g_get_user_runtime_dir() returns the setting of
> XDG_RUNTIME_DIR in the user's environment; usually this is set to
> /run/user/${UID} (e.g. /run/user/1000) - that directory is created
> when a user first logs in and is owned by the user, but is cleared out
> when the system reboots (more specifically, this directory usually
> resides in a tmpfs, and so disappears when that tmpfs is unmounted).
> 
> But sometimes XDG_RUNTIME_DIR isn't set in the user's environment. In
> that case, g_get_user_runtime_dir() returns ${HOME}/.config
> (e.g. /home/laine/.config). This directory fulfills the first 2
> criteria above, but fails the 3rd. This isn't just some pedantic
> complaint - libvirt actually depends on the directory being cleared
> out during a reboot - otherwise it might think that stale status files
> are indicating active guests when in fact the guests were shutdown
> during the reboot).
> 
> In my opinion this behavior is a bug in Glib - see the requirements
> for XDG_RUNTIME in the FreeDesktop documentation here:
> 
>    https://specifications.freedesktop.org/basedir-spec/latest/#variables
> 
> but they've documented the behavior as proper in the Glib docs for
> g_get_user_runtime_dir(), and so likely will consider it not a bug.
> 
> Beyond that, aside from failing the "must be cleared out during a reboot"
> requirement, use of $HOME/.cache in this way also disturbs SELinux,
> which gives an AVC denial when libvirt (or passt) tries to create a
> file or socket in that directory (the SELinux policy permits use of
> /run/user/$UID, but not of $HOME/.config). We *could* add that to the
> SELinux policy, but since the glib behavior doesn't
> 
> All of the above is a very long leadup to the functionality in this
> patch: rather than blindly accepting the path returned from
> g_get_user_runtime_dir(), we first check if XDG_RUNTIME_DIR is set; if
> it isn't set then we look to see if /run/user/$UID exists and is
> writable by this user, if so we use *that* as the directory for our
> status files. Otherwise (both when XDG_RUNTIME_DIR is set, and when
> /run/user/$UID isn't usable) we fallback to just using the path
> returned by g_get_user_runtime_dir() - that isn't perfect, but it's
> what we were doing before, so at least it's not any worse.
> 
> Resolves: https://issues.redhat.com/browse/RHEL-70222
> Signed-off-by: Laine Stump <laine@redhat.com>
> ---
>  src/util/virutil.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/src/util/virutil.c b/src/util/virutil.c
> index 2abcb282fe..4c7f4b62bc 100644
> --- a/src/util/virutil.c
> +++ b/src/util/virutil.c
> @@ -538,6 +538,28 @@ char *virGetUserRuntimeDirectory(void)
>  #ifdef WIN32
>      return g_strdup(g_get_user_runtime_dir());
>  #else
> +    /* tl;dr - if XDG_RUNTIME_DIR is set, use g_get_user_runtime_dir().
> +     *         if not set, then see if /run/user/$UID works
> +     *         if so, use that, else fallback to g_get_user_runtime_dir()
> +     *
> +     * this is done because the directory returned by
> +     * g_get_user_runtime_dir() when XDG_RUNTIME_DIR isn't set is
> +     * "suboptimal" (it's a location that is owned by the user, but
> +     * isn't erased when the user completely logs out)
> +     */
> +
> +    if (!getenv("XDG_RUNTIME_DIR")) {
> +        g_autofree char *runtime_dir = NULL;
> +        struct stat sb;
> +
> +        runtime_dir = g_strdup_printf("/run/user/%d", getuid());

I'm wondering if this should be geteuid.  (I'm not completely clear
myself, I guess it depends on whether this code could be a called in a
setuid / dropped privileges case, and if so what directory should be
used.)

> +        if (virFileIsDir(runtime_dir) &&
> +            (stat(runtime_dir, &sb) == 0) && (sb.st_mode & S_IWUSR)) {
> +            return g_build_filename(runtime_dir, "libvirt", NULL);
> +        }
> +    }
> +
> +    /* either XDG_RUNTIME_DIR was set, or /run/usr/$UID wasn't writable */
>      return g_build_filename(g_get_user_runtime_dir(), "libvirt", NULL);
>  #endif
>  }

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

On Mon, Feb 17, 2025 at 11:31:32AM +0000, Richard W.M. Jones wrote:
> On Mon, Feb 17, 2025 at 02:14:49AM -0500, Laine Stump wrote:
> > ======
> > 
> > I'm sending this as an RFC just because what it's doing feels kind of
> > dirty - directly examining XDG_RUNTIME_DIR seems like an "end run"
> > around the Glib API. If anyone has a better idea of what to do, please
> > give details :-)
> > 
> > ======
> > 
> > When running unprivileged (i.e. not as root, but as a regular user),
> > libvirt calls g_get_user_runtime_dir() (from Glib) to get the name of
> > a directory where status files can be saved. This is a directory that
> > is 1) writeable by the current user, and 2) will remain there until
> > the host reboots, but then 3) be erased after the reboot. This is used
> > for pidfiles, sockets created to communicate between processes, status
> > XML of active domains, etc.
> > 
> > Normally g_get_user_runtime_dir() returns the setting of
> > XDG_RUNTIME_DIR in the user's environment; usually this is set to
> > /run/user/${UID} (e.g. /run/user/1000) - that directory is created
> > when a user first logs in and is owned by the user, but is cleared out
> > when the system reboots (more specifically, this directory usually
> > resides in a tmpfs, and so disappears when that tmpfs is unmounted).
> > 
> > But sometimes XDG_RUNTIME_DIR isn't set in the user's environment. In
> > that case, g_get_user_runtime_dir() returns ${HOME}/.config
> > (e.g. /home/laine/.config). This directory fulfills the first 2
> > criteria above, but fails the 3rd. This isn't just some pedantic
> > complaint - libvirt actually depends on the directory being cleared
> > out during a reboot - otherwise it might think that stale status files
> > are indicating active guests when in fact the guests were shutdown
> > during the reboot).
> > 
> > In my opinion this behavior is a bug in Glib - see the requirements
> > for XDG_RUNTIME in the FreeDesktop documentation here:
> > 
> >    https://specifications.freedesktop.org/basedir-spec/latest/#variables
> > 
> > but they've documented the behavior as proper in the Glib docs for
> > g_get_user_runtime_dir(), and so likely will consider it not a bug.
> > 
> > Beyond that, aside from failing the "must be cleared out during a reboot"
> > requirement, use of $HOME/.cache in this way also disturbs SELinux,
> > which gives an AVC denial when libvirt (or passt) tries to create a
> > file or socket in that directory (the SELinux policy permits use of
> > /run/user/$UID, but not of $HOME/.config). We *could* add that to the
> > SELinux policy, but since the glib behavior doesn't
> > 
> > All of the above is a very long leadup to the functionality in this
> > patch: rather than blindly accepting the path returned from
> > g_get_user_runtime_dir(), we first check if XDG_RUNTIME_DIR is set; if
> > it isn't set then we look to see if /run/user/$UID exists and is
> > writable by this user, if so we use *that* as the directory for our
> > status files. Otherwise (both when XDG_RUNTIME_DIR is set, and when
> > /run/user/$UID isn't usable) we fallback to just using the path
> > returned by g_get_user_runtime_dir() - that isn't perfect, but it's
> > what we were doing before, so at least it's not any worse.
> > 
> > Resolves: https://issues.redhat.com/browse/RHEL-70222
> > Signed-off-by: Laine Stump <laine@redhat.com>
> > ---
> >  src/util/virutil.c | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/src/util/virutil.c b/src/util/virutil.c
> > index 2abcb282fe..4c7f4b62bc 100644
> > --- a/src/util/virutil.c
> > +++ b/src/util/virutil.c
> > @@ -538,6 +538,28 @@ char *virGetUserRuntimeDirectory(void)
> >  #ifdef WIN32
> >      return g_strdup(g_get_user_runtime_dir());
> >  #else
> > +    /* tl;dr - if XDG_RUNTIME_DIR is set, use g_get_user_runtime_dir().
> > +     *         if not set, then see if /run/user/$UID works
> > +     *         if so, use that, else fallback to g_get_user_runtime_dir()
> > +     *
> > +     * this is done because the directory returned by
> > +     * g_get_user_runtime_dir() when XDG_RUNTIME_DIR isn't set is
> > +     * "suboptimal" (it's a location that is owned by the user, but
> > +     * isn't erased when the user completely logs out)
> > +     */
> > +
> > +    if (!getenv("XDG_RUNTIME_DIR")) {
> > +        g_autofree char *runtime_dir = NULL;
> > +        struct stat sb;
> > +
> > +        runtime_dir = g_strdup_printf("/run/user/%d", getuid());
> 
> I'm wondering if this should be geteuid.  (I'm not completely clear
> myself, I guess it depends on whether this code could be a called in a
> setuid / dropped privileges case, and if so what directory should be
> used.)

We explicitly block such usage

    if (getuid() != geteuid() ||
        getgid() != getegid()) {
        virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
                       _("libvirt.so is not safe to use from setuid/setgid programs"));
        goto error;
    }

It is unsafe because too many things we link to have ELF constructors
that are untrustworthy.

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 :|

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.

>                libvirt actually depends on the directory being cleared
> out during a reboot - otherwise it might think that stale status files
> are indicating active guests when in fact the guests were shutdown
> during the reboot).

We could make our status files robust against host reboots by
storing "/proc/sys/kernel/random/boot_id" in them. If boot_id
has changed, we know the pidfile is stale.


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 :|

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

where $someuser was a user than hadn't logged in since the last host 
reboot (and so therefore /run/user/$someuser-id didn't exist) and then 
checking for /run/user/$someuser-id, and you're correct that it wasn't 
created :-/ (and also :-) I guess)

Of course if that user had previously logged in "normally" since the 
last host reboot, then that login session *would* create 
/run/user/$someuser-id. So what I'm doing in this patch would help in 
some situations, but not all (at least it doesn't make any situation 
*worse* though - if /root/user/$id doesn't exist then it falls back to 
the current behavior).

(As a matter of fact, it seems like we have a problem now that if 
someone does login as userX o a normal session, starts up some guests, 
and the virtqemud process is terminated for some reason and then later 
they use "su userX virsh list" (or whatever) then the newly started 
virtqemud will incorrectly look in $HOME/.cache to find the list of 
currently active guests.)

So other than sticking with the current behavior and requesting an 
SELinux change to allow us to use $HOME/.cache (which wouldn't solve the 
problem in the previous paragraph), I suppose we could just decide that 
/tmp/libvirt-${uid} shouldn't be used by anybody but us, and make *that* 
our backup directory (maybe all the time so that it's consistent).

> 
>>                 libvirt actually depends on the directory being cleared
>> out during a reboot - otherwise it might think that stale status files
>> are indicating active guests when in fact the guests were shutdown
>> during the reboot).
> 
> We could make our status files robust against host reboots by
> storing "/proc/sys/kernel/random/boot_id" in them. If boot_id
> has changed, we know the pidfile is stale.

I haven't checked if there is an *actual* problem of us believing stale 
status files are valid (that was just an idle supposition on my part of 
something that *might* be problematic due to using a misbehaving runtime 
dir), but in general that sounds like a good idea (at least on Linux 
systems). Doesn't solve the SELinux (and presumably AppArmor) problem 
though...

(I guess I need to try something like

1) start a guest with "sudo $user virsh start blah"
2) restart the host
    [we now have a $HOME/.cache populated with status files]
3) again use sudo $user to try several virsh commands that
    would get info from status files to see if anything fails.

)

Fortunately this is only an issue for unprivileged libvirt, and most of 
the drivers don't work unprivileged anyway (right? the only other driver 
I've ever paid attention wrt to this was the network driver).

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

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 :|

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.

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 :|

On Tue, Feb 18, 2025 at 02:50:52PM +0000, Daniel P. Berrangé wrote:
> 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...

Apparently, 'su -' and 'sudo' shouldn't be used anymore if you
want a shell running as a different user which can run arbitrary
apps. Instead you're expected to use

   machinectl shell username@

Or 

   sudo machinectl shell username@

which will get the full set of env info setup.

I find it somewhat dubious to simply re-declare that decades of usage
of 'su' and 'sudo' is now wrong but that's the documented answer:

  https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

Likewise in context of RHEL:

  https://access.redhat.com/solutions/6634751

Anyway, given that this is deliberate behaviour, I'm not convinced that
it is libvirt's job to workaround, even if we think that behaviour is
sub-optimal.

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 :|

On 2/18/25 12:21 PM, Daniel P. Berrangé wrote:
> On Tue, Feb 18, 2025 at 02:50:52PM +0000, Daniel P. Berrangé wrote:
>> 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...
> 
> Apparently, 'su -' and 'sudo' shouldn't be used anymore if you
> want a shell running as a different user which can run arbitrary
> apps. Instead you're expected to use
> 
>     machinectl shell username@
> 
> Or
> 
>     sudo machinectl shell username@
> 
> which will get the full set of env info setup.
> 
> I find it somewhat dubious to simply re-declare that decades of usage
> of 'su' and 'sudo' is now wrong but that's the documented answer:
> 
>    https://github.com/systemd/systemd/issues/7451#issuecomment-346787237
> 
> Likewise in context of RHEL:
> 
>    https://access.redhat.com/solutions/6634751
> 
> Anyway, given that this is deliberate behaviour, I'm not convinced that
> it is libvirt's job to workaround, even if we think that behaviour is
> sub-optimal.

Especially since my workaround ends up being a "breakaround" if 
/run/user/$OTHER_UID doesn't already exist (i.e. if there isn't already 
a user session created for that user in some other way - we try to 
create /run/user/$OTHER_UID/libvirt, and fail), I definitely agree.

Rich suggested online last week that maybe we could log a warning if 
XDG_RUNTIME_DIR hasn't been set in the environment (thus indicating that 
we're being executed via "sudo -u $user" or similar). I made an example 
patch of that and am sending it as an RFC so that anyone who wants can 
try it out and see if it's useful (and also suggest a better warning 
message, maybe pointing to a knowledgebase article with more details).

On 2/17/25 3:11 PM, 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

actually it was "sudo -u $someuser virsh list"

> 
> where $someuser was a user than hadn't logged in since the last host 
> reboot (and so therefore /run/user/$someuser-id didn't exist) and then 
> checking for /run/user/$someuser-id, and you're correct that it wasn't 
> created :-/ (and also :-) I guess)
> 
> Of course if that user had previously logged in "normally" since the 
> last host reboot, then that login session *would* create /run/user/ 
> $someuser-id. So what I'm doing in this patch would help in some 
> situations, but not all (at least it doesn't make any situation *worse* 
> though - if /root/user/$id doesn't exist then it falls back to the 
> current behavior).
> 
> (As a matter of fact, it seems like we have a problem now that if 
> someone does login as userX o a normal session, starts up some guests, 
> and the virtqemud process is terminated for some reason and then later 
> they use "su userX virsh list" (or whatever) then the newly started 
> virtqemud will incorrectly look in $HOME/.cache to find the list of 
> currently active guests.)
> 
> So other than sticking with the current behavior and requesting an 
> SELinux change to allow us to use $HOME/.cache (which wouldn't solve the 
> problem in the previous paragraph), I suppose we could just decide 
> that /tmp/libvirt-${uid} shouldn't be used by anybody but us, and make 
> *that* our backup directory (maybe all the time so that it's consistent).
> 
>>
>>>                 libvirt actually depends on the directory being cleared
>>> out during a reboot - otherwise it might think that stale status files
>>> are indicating active guests when in fact the guests were shutdown
>>> during the reboot).
>>
>> We could make our status files robust against host reboots by
>> storing "/proc/sys/kernel/random/boot_id" in them. If boot_id
>> has changed, we know the pidfile is stale.
> 
> I haven't checked if there is an *actual* problem of us believing stale 
> status files are valid (that was just an idle supposition on my part of 
> something that *might* be problematic due to using a misbehaving runtime 
> dir), but in general that sounds like a good idea (at least on Linux 
> systems). Doesn't solve the SELinux (and presumably AppArmor) problem 
> though...
> 
> (I guess I need to try something like
> 
> 1) start a guest with "sudo $user virsh start blah"
> 2) restart the host
>     [we now have a $HOME/.cache populated with status files]
> 3) again use sudo $user to try several virsh commands that
>     would get info from status files to see if anything fails.
> 
> )

An example of the opposite that I tried - if I login as $someuser and 
"virsh start blah", then separately (without rebooting the host) as a 
different user I run "sudo -u $someuser virsh list", I will get back an 
empty list (because 1) for some reason (also probably related to lack of 
environment) a 2nd virtqemud process is started, and 2) the new instance 
of virtqemud doesn't have XDG_RUNTIME_DIR set, so it's looking in 
$HOME/.cache)

> 
> Fortunately this is only an issue for unprivileged libvirt, and most of 
> the drivers don't work unprivileged anyway (right? the only other driver 
> I've ever paid attention wrt to this was the network driver).

On Mon, Feb 17, 2025 at 02:14:49AM -0500, Laine Stump wrote:
>======
>
>I'm sending this as an RFC just because what it's doing feels kind of
>dirty - directly examining XDG_RUNTIME_DIR seems like an "end run"
>around the Glib API. If anyone has a better idea of what to do, please
>give details :-)
>
>======
>
>When running unprivileged (i.e. not as root, but as a regular user),
>libvirt calls g_get_user_runtime_dir() (from Glib) to get the name of
>a directory where status files can be saved. This is a directory that
>is 1) writeable by the current user, and 2) will remain there until
>the host reboots, but then 3) be erased after the reboot. This is used
>for pidfiles, sockets created to communicate between processes, status
>XML of active domains, etc.
>
>Normally g_get_user_runtime_dir() returns the setting of
>XDG_RUNTIME_DIR in the user's environment; usually this is set to
>/run/user/${UID} (e.g. /run/user/1000) - that directory is created
>when a user first logs in and is owned by the user, but is cleared out
>when the system reboots (more specifically, this directory usually
>resides in a tmpfs, and so disappears when that tmpfs is unmounted).
>
>But sometimes XDG_RUNTIME_DIR isn't set in the user's environment. In
>that case, g_get_user_runtime_dir() returns ${HOME}/.config
>(e.g. /home/laine/.config). This directory fulfills the first 2

it's ~/.cache, not ~/.config

>criteria above, but fails the 3rd. This isn't just some pedantic
>complaint - libvirt actually depends on the directory being cleared
>out during a reboot - otherwise it might think that stale status files
>are indicating active guests when in fact the guests were shutdown
>during the reboot).
>

We should be able to cope with such files existing no matter what.  It
might not be a reboot, but restart of the daemon during which the domain
dies etc. and we should handle that properly.  If we do not, then there
is some other underlying problem we should still strive to solve.

>In my opinion this behavior is a bug in Glib - see the requirements
>for XDG_RUNTIME in the FreeDesktop documentation here:
>
>   https://specifications.freedesktop.org/basedir-spec/latest/#variables
>
>but they've documented the behavior as proper in the Glib docs for
>g_get_user_runtime_dir(), and so likely will consider it not a bug.
>
>Beyond that, aside from failing the "must be cleared out during a reboot"
>requirement, use of $HOME/.cache in this way also disturbs SELinux,
>which gives an AVC denial when libvirt (or passt) tries to create a
>file or socket in that directory (the SELinux policy permits use of
>/run/user/$UID, but not of $HOME/.config). We *could* add that to the
>SELinux policy, but since the glib behavior doesn't
>
>All of the above is a very long leadup to the functionality in this
>patch: rather than blindly accepting the path returned from
>g_get_user_runtime_dir(), we first check if XDG_RUNTIME_DIR is set; if
>it isn't set then we look to see if /run/user/$UID exists and is
>writable by this user, if so we use *that* as the directory for our
>status files. Otherwise (both when XDG_RUNTIME_DIR is set, and when
>/run/user/$UID isn't usable) we fallback to just using the path
>returned by g_get_user_runtime_dir() - that isn't perfect, but it's
>what we were doing before, so at least it's not any worse.
>
>Resolves: https://issues.redhat.com/browse/RHEL-70222
>Signed-off-by: Laine Stump <laine@redhat.com>
>---
> src/util/virutil.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
>diff --git a/src/util/virutil.c b/src/util/virutil.c
>index 2abcb282fe..4c7f4b62bc 100644
>--- a/src/util/virutil.c
>+++ b/src/util/virutil.c
>@@ -538,6 +538,28 @@ char *virGetUserRuntimeDirectory(void)
> #ifdef WIN32
>     return g_strdup(g_get_user_runtime_dir());
> #else
>+    /* tl;dr - if XDG_RUNTIME_DIR is set, use g_get_user_runtime_dir().
>+     *         if not set, then see if /run/user/$UID works
>+     *         if so, use that, else fallback to g_get_user_runtime_dir()
>+     *
>+     * this is done because the directory returned by
>+     * g_get_user_runtime_dir() when XDG_RUNTIME_DIR isn't set is
>+     * "suboptimal" (it's a location that is owned by the user, but
>+     * isn't erased when the user completely logs out)
>+     */
>+
>+    if (!getenv("XDG_RUNTIME_DIR")) {
>+        g_autofree char *runtime_dir = NULL;
>+        struct stat sb;
>+
>+        runtime_dir = g_strdup_printf("/run/user/%d", getuid());
>+        if (virFileIsDir(runtime_dir) &&
>+            (stat(runtime_dir, &sb) == 0) && (sb.st_mode & S_IWUSR)) {
>+            return g_build_filename(runtime_dir, "libvirt", NULL);
>+        }
>+    }
>+
>+    /* either XDG_RUNTIME_DIR was set, or /run/usr/$UID wasn't writable */
>     return g_build_filename(g_get_user_runtime_dir(), "libvirt", NULL);
> #endif
> }
>-- 
>2.47.1
>

On 2/17/25 5:02 AM, Martin Kletzander wrote:
> On Mon, Feb 17, 2025 at 02:14:49AM -0500, Laine Stump wrote:
>> ======
>>
>> I'm sending this as an RFC just because what it's doing feels kind of
>> dirty - directly examining XDG_RUNTIME_DIR seems like an "end run"
>> around the Glib API. If anyone has a better idea of what to do, please
>> give details :-)
>>
>> ======
>>
>> When running unprivileged (i.e. not as root, but as a regular user),
>> libvirt calls g_get_user_runtime_dir() (from Glib) to get the name of
>> a directory where status files can be saved. This is a directory that
>> is 1) writeable by the current user, and 2) will remain there until
>> the host reboots, but then 3) be erased after the reboot. This is used
>> for pidfiles, sockets created to communicate between processes, status
>> XML of active domains, etc.
>>
>> Normally g_get_user_runtime_dir() returns the setting of
>> XDG_RUNTIME_DIR in the user's environment; usually this is set to
>> /run/user/${UID} (e.g. /run/user/1000) - that directory is created
>> when a user first logs in and is owned by the user, but is cleared out
>> when the system reboots (more specifically, this directory usually
>> resides in a tmpfs, and so disappears when that tmpfs is unmounted).
>>
>> But sometimes XDG_RUNTIME_DIR isn't set in the user's environment. In
>> that case, g_get_user_runtime_dir() returns ${HOME}/.config
>> (e.g. /home/laine/.config). This directory fulfills the first 2
> 
> it's ~/.cache, not ~/.config


Yeah, sorry - that's what happens when I try to type up a commit log 
message at 2AM :-)

> 
>> criteria above, but fails the 3rd. This isn't just some pedantic
>> complaint - libvirt actually depends on the directory being cleared
>> out during a reboot - otherwise it might think that stale status files
>> are indicating active guests when in fact the guests were shutdown
>> during the reboot).
>>
> 
> We should be able to cope with such files existing no matter what.  It
> might not be a reboot, but restart of the daemon during which the domain
> dies etc. and we should handle that properly.  If we do not, then there
> is some other underlying problem we should still strive to solve.

Well, that part of my explanation for the reasoning behind the change 
was just random supposition on my part. The main reason that made me 
look into it is that when $HOME/.cache is used as the runtime dir, the 
SELinux policies puke because there is no label saying that directory is 
okay for us to write stuff. I only mention this other problem because 
its a behavior we don't expect (although you're correct that if we don't 
handle it properly anyway then that's a paddli.. er I mean bug.

>> In my opinion this behavior is a bug in Glib - see the requirements
>> for XDG_RUNTIME in the FreeDesktop documentation here:
>>
>>   https://specifications.freedesktop.org/basedir-spec/latest/#variables

and as this document points out, it's not the generally expected 
behavior for XDG_RUNTIME_DIR - that doc explicitly says that the 
directory MUST be deleted when the host reboots.

>>
>> but they've documented the behavior as proper in the Glib docs for
>> g_get_user_runtime_dir(), and so likely will consider it not a bug.

...although the *same organization* documents that their function 
returning a "runtime_dir" will return something that specifically breaks 
that rule. (And due to it being documented, I'm guessing they won't want 
to change it)

>>
>> Beyond that, aside from failing the "must be cleared out during a reboot"
>> requirement, use of $HOME/.cache in this way also disturbs SELinux,
>> which gives an AVC denial when libvirt (or passt) tries to create a
>> file or socket in that directory (the SELinux policy permits use of
>> /run/user/$UID, but not of $HOME/.config). We *could* add that to the
>> SELinux policy, but since the glib behavior doesn't
>>
>> All of the above is a very long leadup to the functionality in this
>> patch: rather than blindly accepting the path returned from
>> g_get_user_runtime_dir(), we first check if XDG_RUNTIME_DIR is set; if
>> it isn't set then we look to see if /run/user/$UID exists and is
>> writable by this user, if so we use *that* as the directory for our
>> status files. Otherwise (both when XDG_RUNTIME_DIR is set, and when
>> /run/user/$UID isn't usable) we fallback to just using the path
>> returned by g_get_user_runtime_dir() - that isn't perfect, but it's
>> what we were doing before, so at least it's not any worse.
>>
>> Resolves: https://issues.redhat.com/browse/RHEL-70222
>> Signed-off-by: Laine Stump <laine@redhat.com>
>> ---
>> src/util/virutil.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/src/util/virutil.c b/src/util/virutil.c
>> index 2abcb282fe..4c7f4b62bc 100644
>> --- a/src/util/virutil.c
>> +++ b/src/util/virutil.c
>> @@ -538,6 +538,28 @@ char *virGetUserRuntimeDirectory(void)
>> #ifdef WIN32
>>     return g_strdup(g_get_user_runtime_dir());
>> #else
>> +    /* tl;dr - if XDG_RUNTIME_DIR is set, use g_get_user_runtime_dir().
>> +     *         if not set, then see if /run/user/$UID works
>> +     *         if so, use that, else fallback to 
>> g_get_user_runtime_dir()
>> +     *
>> +     * this is done because the directory returned by
>> +     * g_get_user_runtime_dir() when XDG_RUNTIME_DIR isn't set is
>> +     * "suboptimal" (it's a location that is owned by the user, but
>> +     * isn't erased when the user completely logs out)
>> +     */
>> +
>> +    if (!getenv("XDG_RUNTIME_DIR")) {
>> +        g_autofree char *runtime_dir = NULL;
>> +        struct stat sb;
>> +
>> +        runtime_dir = g_strdup_printf("/run/user/%d", getuid());
>> +        if (virFileIsDir(runtime_dir) &&
>> +            (stat(runtime_dir, &sb) == 0) && (sb.st_mode & S_IWUSR)) {
>> +            return g_build_filename(runtime_dir, "libvirt", NULL);
>> +        }
>> +    }
>> +
>> +    /* either XDG_RUNTIME_DIR was set, or /run/usr/$UID wasn't 
>> writable */
>>     return g_build_filename(g_get_user_runtime_dir(), "libvirt", NULL);
>> #endif
>> }
>> -- 
>> 2.47.1
>>