[PATCH] test: Update README.md

[PATCH] test: Update README.md

[Yumei Huang]

Signed-off-by: Yumei Huang <yuhuang@redhat.com>
---
 test/README.md | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/test/README.md b/test/README.md
index 91ca603..e3e9d37 100644
--- a/test/README.md
+++ b/test/README.md
@@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
     git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
     lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
     qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
-    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
+    sipcalc socat strace tmux uidmap valgrind
 
 NOTE: the tests need a qemu version >= 7.2, or one that contains commit
 13c6be96618c ("net: stream: add unix socket"): this change introduces support
@@ -81,7 +81,12 @@ The following additional packages are commonly needed:
 
 ## Regular test
 
-Just issue:
+Before running the tests, you need to prepare the required assets:
+
+    cd test
+    make assets
+
+Then issue:
 
     ./run
 
@@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
 
     PCAP=1 TRACE=1 ./run
 
+**Note:**
+
+* It's recommended to run the commands as a non-root user.
+  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
+  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
+  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
+  `/run/user/0` instead of `/run/user/ID`, which can cause error.
+
+  **Workaround:** Log out and log back in as the intended user to ensure the
+  correct runtime directory is set up.
+
+* SELinux may prevent the tests from running correctly. To avoid this,
+  temporarily disable it by running:
+
+        setenforce 0
+
+* Some tests require a QEMU build that includes the following commits:
+
+        60f543ad917f ("virtio-net: vhost-user: Implement internal migration")
+        3f65357313e0 ("vhost: Add stubs for the migration state transfer
+        interface")
+
 ## Running selected tests
 
 Rudimentary support to run a list of selected tests, without support for
-- 
2.47.0

Re: [PATCH] test: Update README.md

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

On Fri, Sep 19, 2025 at 09:43:29AM +0800, Yumei Huang wrote:
> Signed-off-by: Yumei Huang <yuhuang@redhat.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

We may well want further updates, but this is a strict improvement on
what we have now.

> ---
>  test/README.md | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/test/README.md b/test/README.md
> index 91ca603..e3e9d37 100644
> --- a/test/README.md
> +++ b/test/README.md
> @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
>      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
>      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
>      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> +    sipcalc socat strace tmux uidmap valgrind
>  
>  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
>  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
>  
>  ## Regular test
>  
> -Just issue:
> +Before running the tests, you need to prepare the required assets:
> +
> +    cd test
> +    make assets
> +
> +Then issue:
>  
>      ./run
>  
> @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
>  
>      PCAP=1 TRACE=1 ./run
>  
> +**Note:**
> +
> +* It's recommended to run the commands as a non-root user.
> +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> +
> +  **Workaround:** Log out and log back in as the intended user to ensure the
> +  correct runtime directory is set up.
> +
> +* SELinux may prevent the tests from running correctly. To avoid this,
> +  temporarily disable it by running:
> +
> +        setenforce 0
> +
> +* Some tests require a QEMU build that includes the following commits:
> +
> +        60f543ad917f ("virtio-net: vhost-user: Implement internal migration")
> +        3f65357313e0 ("vhost: Add stubs for the migration state transfer
> +        interface")
> +
>  ## Running selected tests
>  
>  Rudimentary support to run a list of selected tests, without support for
> -- 
> 2.47.0
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] test: Update README.md

[Stefano Brivio]

On Fri, 19 Sep 2025 09:43:29 +0800
Yumei Huang <yuhuang@redhat.com> wrote:

> Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> ---
>  test/README.md | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/test/README.md b/test/README.md
> index 91ca603..e3e9d37 100644
> --- a/test/README.md
> +++ b/test/README.md
> @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
>      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
>      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
>      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> +    sipcalc socat strace tmux uidmap valgrind
>  
>  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
>  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
>  
>  ## Regular test
>  
> -Just issue:
> +Before running the tests, you need to prepare the required assets:
> +
> +    cd test
> +    make assets
> +
> +Then issue:
>  
>      ./run
>  
> @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
>  
>      PCAP=1 TRACE=1 ./run
>  
> +**Note:**
> +
> +* It's recommended to run the commands as a non-root user.
> +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> +  `/run/user/0` instead of `/run/user/ID`, which can cause error.

Thanks for the research, I wasn't aware of that, and recently spent
quite some time figuring that out (for other reasons):

  https://issues.redhat.com/browse/RHEL-70222

in that case, XDG_RUNTIME_DIR was simply not set. Things were working
with 'machinectl shell' instead.

At the same time: running this whole stuff as root sounds rather crazy,
unless it's a throw-away VMs with absolutely nothing important on it.

That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
make the wording stronger, something like:

* Don't run the tests as root, it's not needed!
* If you really need to, note that ...

> +  **Workaround:** Log out and log back in as the intended user to ensure the
> +  correct runtime directory is set up.

We could also suggest 'machinectl shell' if it's really needed for
whatever reason.

> +* SELinux may prevent the tests from running correctly. To avoid this,
> +  temporarily disable it by running:
> +
> +        setenforce 0

By the way, other than the DHCP client not working on Fedora in a
namespace (which we should really fix, I can look into it if you share
the messages you're getting from /var/log/audit/audit.log), did you hit
any other issue with it?

I haven't tried running tests on Fedora for a long time now.

> +* Some tests require a QEMU build that includes the following commits:
> +
> +        60f543ad917f ("virtio-net: vhost-user: Implement internal migration")
> +        3f65357313e0 ("vhost: Add stubs for the migration state transfer
> +        interface")

Given:

  $ git describe --contain 60f543ad917f 3f65357313e0
  v10.0.0-rc0~89^2~1
  v10.0.0-rc0~89^2~2

we might also save the reader from checking out a QEMU tree to check
and say something like "Some tests require a QEMU version >= 10.0.0, or
a build that includes ..."

> +
>  ## Running selected tests
>  
>  Rudimentary support to run a list of selected tests, without support for

The rest looks good to me and it's an improvement on the original
anyway so I'm fine applying as it is, as well, but those few
suggestions shouldn't take that long either.

-- 
Stefano

Re: [PATCH] test: Update README.md

[Yumei Huang]

On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Fri, 19 Sep 2025 09:43:29 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
>
> > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > ---
> >  test/README.md | 31 +++++++++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/test/README.md b/test/README.md
> > index 91ca603..e3e9d37 100644
> > --- a/test/README.md
> > +++ b/test/README.md
> > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > +    sipcalc socat strace tmux uidmap valgrind
> >
> >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> >
> >  ## Regular test
> >
> > -Just issue:
> > +Before running the tests, you need to prepare the required assets:
> > +
> > +    cd test
> > +    make assets
> > +
> > +Then issue:
> >
> >      ./run
> >
> > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> >
> >      PCAP=1 TRACE=1 ./run
> >
> > +**Note:**
> > +
> > +* It's recommended to run the commands as a non-root user.
> > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
>
> Thanks for the research, I wasn't aware of that, and recently spent
> quite some time figuring that out (for other reasons):
>
>   https://issues.redhat.com/browse/RHEL-70222
>
> in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> with 'machinectl shell' instead.
>
> At the same time: running this whole stuff as root sounds rather crazy,
> unless it's a throw-away VMs with absolutely nothing important on it.
>
> That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> make the wording stronger, something like:
>
> * Don't run the tests as root, it's not needed!
> * If you really need to, note that ...
>
> > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > +  correct runtime directory is set up.
>
> We could also suggest 'machinectl shell' if it's really needed for
> whatever reason.

I'm not sure how 'machinectl shell' works here. The error happens when
running 'make assets',
which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.

If we run 'make assets' with root, the error is like this:

./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
libguestfs: error: could not create appliance through libvirt.
Original error from libvirt: Cannot access storage file
'/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
(as uid:107, gid:107): Permission denied [code=38 int1=13]

If we switch to a non-root user via 'su', the error is like this:

./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
libvirt: XML-RPC error : Cannot create user runtime directory
'/run/user/0/libvirt': Permission denied
libguestfs: error: could not connect to libvirt (URI =
qemu:///session): Cannot create user runtime directory
'/run/user/0/libvirt': Permission denied [code=38 int1=13]
make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1

Do you mean to run 'make assets' with 'machinectl shell'? What's the
exact cmd here? I tried this, seems not work.

    # machinectl shell --uid=$(id -u pat) .host
/home/test/passt/test/make assets
    Connected to the local host. Press ^] three times within 1s to exit session.

    Connection to the local host terminated.

>
> > +* SELinux may prevent the tests from running correctly. To avoid this,
> > +  temporarily disable it by running:
> > +
> > +        setenforce 0
>
> By the way, other than the DHCP client not working on Fedora in a
> namespace (which we should really fix, I can look into it if you share
> the messages you're getting from /var/log/audit/audit.log), did you hit
> any other issue with it?
>

Sure, I will send you a link containing the audit.log.
BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
:address'. Looks like an endless loop there. So except the very first
few tests, other tests haven't been executed.

=== pasta/dhcp
DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>
Interface name
DEBUG:DEBUG:? [ -n "eno8303" ]
DEBUG:DEBUG:...passed.

> DHCP: address
DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
DEBUG:DEBUG:...failed.

> DHCP: route
DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
DEBUG:DEBUG:...failed.

> DHCP: MTU
DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
DEBUG:DEBUG:...failed.

> DHCPv6: address
DEBUG:


> I haven't tried running tests on Fedora for a long time now.
>
> > +* Some tests require a QEMU build that includes the following commits:
> > +
> > +        60f543ad917f ("virtio-net: vhost-user: Implement internal migration")
> > +        3f65357313e0 ("vhost: Add stubs for the migration state transfer
> > +        interface")
>
> Given:
>
>   $ git describe --contain 60f543ad917f 3f65357313e0
>   v10.0.0-rc0~89^2~1
>   v10.0.0-rc0~89^2~2
>
> we might also save the reader from checking out a QEMU tree to check
> and say something like "Some tests require a QEMU version >= 10.0.0, or
> a build that includes ..."
>

Good idea! Will update in v2.
> > +
> >  ## Running selected tests
> >
> >  Rudimentary support to run a list of selected tests, without support for
>
> The rest looks good to me and it's an improvement on the original
> anyway so I'm fine applying as it is, as well, but those few
> suggestions shouldn't take that long either.

Sure, those are good suggestions. Thanks!
>
> --
> Stefano
>


-- 
Thanks,

Yumei Huang

Re: [PATCH] test: Update README.md

[Stefano Brivio]

On Mon, 22 Sep 2025 11:03:23 +0800
Yumei Huang <yuhuang@redhat.com> wrote:

> On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Fri, 19 Sep 2025 09:43:29 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >  
> > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > ---
> > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/test/README.md b/test/README.md
> > > index 91ca603..e3e9d37 100644
> > > --- a/test/README.md
> > > +++ b/test/README.md
> > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > +    sipcalc socat strace tmux uidmap valgrind
> > >
> > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > >
> > >  ## Regular test
> > >
> > > -Just issue:
> > > +Before running the tests, you need to prepare the required assets:
> > > +
> > > +    cd test
> > > +    make assets
> > > +
> > > +Then issue:
> > >
> > >      ./run
> > >
> > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > >
> > >      PCAP=1 TRACE=1 ./run
> > >
> > > +**Note:**
> > > +
> > > +* It's recommended to run the commands as a non-root user.
> > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.  
> >
> > Thanks for the research, I wasn't aware of that, and recently spent
> > quite some time figuring that out (for other reasons):
> >
> >   https://issues.redhat.com/browse/RHEL-70222
> >
> > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > with 'machinectl shell' instead.
> >
> > At the same time: running this whole stuff as root sounds rather crazy,
> > unless it's a throw-away VMs with absolutely nothing important on it.
> >
> > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > make the wording stronger, something like:
> >
> > * Don't run the tests as root, it's not needed!
> > * If you really need to, note that ...
> >  
> > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > +  correct runtime directory is set up.  
> >
> > We could also suggest 'machinectl shell' if it's really needed for
> > whatever reason.  
> 
> I'm not sure how 'machinectl shell' works here. The error happens when
> running 'make assets',
> which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.

Ah, I didn't know! So this is actually similar to
https://issues.redhat.com/browse/RHEL-70222.

> If we run 'make assets' with root, the error is like this:
> 
> ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> libguestfs: error: could not create appliance through libvirt.
> Original error from libvirt: Cannot access storage file
> '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> (as uid:107, gid:107): Permission denied [code=38 int1=13]
> 
> If we switch to a non-root user via 'su', the error is like this:
> 
> ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> libvirt: XML-RPC error : Cannot create user runtime directory
> '/run/user/0/libvirt': Permission denied
> libguestfs: error: could not connect to libvirt (URI =
> qemu:///session): Cannot create user runtime directory
> '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> 
> Do you mean to run 'make assets' with 'machinectl shell'? What's the
> exact cmd here? I tried this, seems not work.
> 
>     # machinectl shell --uid=$(id -u pat) .host
> /home/test/passt/test/make assets
>     Connected to the local host. Press ^] three times within 1s to exit session.
> 
>     Connection to the local host terminated.

No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
replacement), that is:

    $ machinectl shell
    # make assets

...because that one will set XDG_RUNTIME_DIR.

> > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > +  temporarily disable it by running:
> > > +
> > > +        setenforce 0  
> >
> > By the way, other than the DHCP client not working on Fedora in a
> > namespace (which we should really fix, I can look into it if you share
> > the messages you're getting from /var/log/audit/audit.log), did you hit
> > any other issue with it?
> >  
> 
> Sure, I will send you a link containing the audit.log.
> BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> :address'. Looks like an endless loop there. So except the very first
> few tests, other tests haven't been executed.
> 
> === pasta/dhcp
> DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>  
> Interface name
> DEBUG:DEBUG:? [ -n "eno8303" ]
> DEBUG:DEBUG:...passed.
> 
> > DHCP: address  
> DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> DEBUG:DEBUG:...failed.
> 
> > DHCP: route  
> DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> DEBUG:DEBUG:...failed.
> 
> > DHCP: MTU  
> DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> DEBUG:DEBUG:...failed.
> 
> > DHCPv6: address  
> DEBUG:

Thanks, so it's the issue David recently mentioned with
dhclient-script(8) being prevented by SELinux from setting up addresses
and routes via ip(8), even though it's in a detached namespace and that
should be allowed.

We should probably add something like we do in contrib/selinux/pasta.te
to https://github.com/fedora-selinux/selinux-policy:

  roleattribute user_r usernetctl_roles;
  role usernetctl_roles types <whatever dhclient runs as>;

Now, we can disable SELinux temporarily to run tests, but eventually
we'll want to have tests with DHCP clients in unprivileged setups also
as part of Fedora automated tests, and I'm fairly sure that those run
with SELinux in enforcing mode. So we should really fix this.

By the way, it would also be interesting to see if, once the test suite
gets past this point, you get further messages in audit.log.

If you do 'setenforce 0', SELinux switches to the so-called "complain
mode", and warnings are still logged, but they won't block anything.

So, with 'setenforce 0', we can find out from audit.log if we would hit
further failures.

Maybe also relevant:

  https://github.com/fedora-selinux/selinux-policy/pull/1838

...but it's not being merged for some reason.

-- 
Stefano

Re: [PATCH] test: Update README.md

[Yumei Huang]

On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Mon, 22 Sep 2025 11:03:23 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
>
> > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > >
> > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > Yumei Huang <yuhuang@redhat.com> wrote:
> > >
> > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > ---
> > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/test/README.md b/test/README.md
> > > > index 91ca603..e3e9d37 100644
> > > > --- a/test/README.md
> > > > +++ b/test/README.md
> > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > +    sipcalc socat strace tmux uidmap valgrind
> > > >
> > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > >
> > > >  ## Regular test
> > > >
> > > > -Just issue:
> > > > +Before running the tests, you need to prepare the required assets:
> > > > +
> > > > +    cd test
> > > > +    make assets
> > > > +
> > > > +Then issue:
> > > >
> > > >      ./run
> > > >
> > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > >
> > > >      PCAP=1 TRACE=1 ./run
> > > >
> > > > +**Note:**
> > > > +
> > > > +* It's recommended to run the commands as a non-root user.
> > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> > >
> > > Thanks for the research, I wasn't aware of that, and recently spent
> > > quite some time figuring that out (for other reasons):
> > >
> > >   https://issues.redhat.com/browse/RHEL-70222
> > >
> > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > with 'machinectl shell' instead.
> > >
> > > At the same time: running this whole stuff as root sounds rather crazy,
> > > unless it's a throw-away VMs with absolutely nothing important on it.
> > >
> > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > make the wording stronger, something like:
> > >
> > > * Don't run the tests as root, it's not needed!
> > > * If you really need to, note that ...
> > >
> > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > +  correct runtime directory is set up.
> > >
> > > We could also suggest 'machinectl shell' if it's really needed for
> > > whatever reason.
> >
> > I'm not sure how 'machinectl shell' works here. The error happens when
> > running 'make assets',
> > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.
>
> Ah, I didn't know! So this is actually similar to
> https://issues.redhat.com/browse/RHEL-70222.
>
> > If we run 'make assets' with root, the error is like this:
> >
> > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > libguestfs: error: could not create appliance through libvirt.
> > Original error from libvirt: Cannot access storage file
> > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> >
> > If we switch to a non-root user via 'su', the error is like this:
> >
> > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > libvirt: XML-RPC error : Cannot create user runtime directory
> > '/run/user/0/libvirt': Permission denied
> > libguestfs: error: could not connect to libvirt (URI =
> > qemu:///session): Cannot create user runtime directory
> > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> >
> > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > exact cmd here? I tried this, seems not work.
> >
> >     # machinectl shell --uid=$(id -u pat) .host
> > /home/test/passt/test/make assets
> >     Connected to the local host. Press ^] three times within 1s to exit session.
> >
> >     Connection to the local host terminated.
>
> No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> replacement), that is:
>
>     $ machinectl shell
>     # make assets
>
> ...because that one will set XDG_RUNTIME_DIR.

Yes, 'machinectl shell' will solve the issue when switching to a
non-root user via su. But it doesn't solve the issue when running
'make assets' as root. They are actually different issues as above.
Maybe we can just put it like:

    Running the commands as root is just not allowed.  If you login
the system with root, don't use su to switch users due to [Bug
967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
and log back in as the intended user, or use 'machinectl shell
--uid=$user'.

What do you think?
>
> > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > +  temporarily disable it by running:
> > > > +
> > > > +        setenforce 0
> > >
> > > By the way, other than the DHCP client not working on Fedora in a
> > > namespace (which we should really fix, I can look into it if you share
> > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > any other issue with it?
> > >
> >
> > Sure, I will send you a link containing the audit.log.
> > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > :address'. Looks like an endless loop there. So except the very first
> > few tests, other tests haven't been executed.
> >
> > === pasta/dhcp
> > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>
> > Interface name
> > DEBUG:DEBUG:? [ -n "eno8303" ]
> > DEBUG:DEBUG:...passed.
> >
> > > DHCP: address
> > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > DEBUG:DEBUG:...failed.
> >
> > > DHCP: route
> > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > DEBUG:DEBUG:...failed.
> >
> > > DHCP: MTU
> > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > DEBUG:DEBUG:...failed.
> >
> > > DHCPv6: address
> > DEBUG:
>
> Thanks, so it's the issue David recently mentioned with
> dhclient-script(8) being prevented by SELinux from setting up addresses
> and routes via ip(8), even though it's in a detached namespace and that
> should be allowed.
>
> We should probably add something like we do in contrib/selinux/pasta.te
> to https://github.com/fedora-selinux/selinux-policy:
>
>   roleattribute user_r usernetctl_roles;
>   role usernetctl_roles types <whatever dhclient runs as>;
>
> Now, we can disable SELinux temporarily to run tests, but eventually
> we'll want to have tests with DHCP clients in unprivileged setups also
> as part of Fedora automated tests, and I'm fairly sure that those run
> with SELinux in enforcing mode. So we should really fix this.

Sure, I will file a ticket for that.
>
> By the way, it would also be interesting to see if, once the test suite
> gets past this point, you get further messages in audit.log.
>
> If you do 'setenforce 0', SELinux switches to the so-called "complain
> mode", and warnings are still logged, but they won't block anything.
>
> So, with 'setenforce 0', we can find out from audit.log if we would hit
> further failures.

Here is the audit.log:

https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb

From what I can see, there is no 'avc:  denied' after the dhcp cases.

>
> Maybe also relevant:
>
>   https://github.com/fedora-selinux/selinux-policy/pull/1838
>
> ...but it's not being merged for some reason.
>
> --
> Stefano
>


-- 
Thanks,

Yumei Huang

Re: [PATCH] test: Update README.md

[Yumei Huang]

[-- Attachment #1: Type: text/plain, Size: 9110 bytes --]

On Tue, Sep 23, 2025 at 2:36 PM Yumei Huang <yuhuang@redhat.com> wrote:
>
> On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Mon, 22 Sep 2025 11:03:23 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >
> > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > >
> > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > >
> > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > ---
> > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/test/README.md b/test/README.md
> > > > > index 91ca603..e3e9d37 100644
> > > > > --- a/test/README.md
> > > > > +++ b/test/README.md
> > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > >
> > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > >
> > > > >  ## Regular test
> > > > >
> > > > > -Just issue:
> > > > > +Before running the tests, you need to prepare the required assets:
> > > > > +
> > > > > +    cd test
> > > > > +    make assets
> > > > > +
> > > > > +Then issue:
> > > > >
> > > > >      ./run
> > > > >
> > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > >
> > > > >      PCAP=1 TRACE=1 ./run
> > > > >
> > > > > +**Note:**
> > > > > +
> > > > > +* It's recommended to run the commands as a non-root user.
> > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> > > >
> > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > quite some time figuring that out (for other reasons):
> > > >
> > > >   https://issues.redhat.com/browse/RHEL-70222
> > > >
> > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > with 'machinectl shell' instead.
> > > >
> > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > >
> > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > make the wording stronger, something like:
> > > >
> > > > * Don't run the tests as root, it's not needed!
> > > > * If you really need to, note that ...
> > > >
> > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > +  correct runtime directory is set up.
> > > >
> > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > whatever reason.
> > >
> > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > running 'make assets',
> > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.
> >
> > Ah, I didn't know! So this is actually similar to
> > https://issues.redhat.com/browse/RHEL-70222.
> >
> > > If we run 'make assets' with root, the error is like this:
> > >
> > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > libguestfs: error: could not create appliance through libvirt.
> > > Original error from libvirt: Cannot access storage file
> > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > >
> > > If we switch to a non-root user via 'su', the error is like this:
> > >
> > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > '/run/user/0/libvirt': Permission denied
> > > libguestfs: error: could not connect to libvirt (URI =
> > > qemu:///session): Cannot create user runtime directory
> > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > >
> > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > exact cmd here? I tried this, seems not work.
> > >
> > >     # machinectl shell --uid=$(id -u pat) .host
> > > /home/test/passt/test/make assets
> > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > >
> > >     Connection to the local host terminated.
> >
> > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > replacement), that is:
> >
> >     $ machinectl shell
> >     # make assets
> >
> > ...because that one will set XDG_RUNTIME_DIR.
>
> Yes, 'machinectl shell' will solve the issue when switching to a
> non-root user via su. But it doesn't solve the issue when running
> 'make assets' as root. They are actually different issues as above.
> Maybe we can just put it like:
>
>     Running the commands as root is just not allowed.  If you login
> the system with root, don't use su to switch users due to [Bug
> 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> and log back in as the intended user, or use 'machinectl shell
> --uid=$user'.
>
> What do you think?
> >
> > > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > > +  temporarily disable it by running:
> > > > > +
> > > > > +        setenforce 0
> > > >
> > > > By the way, other than the DHCP client not working on Fedora in a
> > > > namespace (which we should really fix, I can look into it if you share
> > > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > > any other issue with it?
> > > >
> > >
> > > Sure, I will send you a link containing the audit.log.
> > > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > > :address'. Looks like an endless loop there. So except the very first
> > > few tests, other tests haven't been executed.
> > >
> > > === pasta/dhcp
> > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>
> > > Interface name
> > > DEBUG:DEBUG:? [ -n "eno8303" ]
> > > DEBUG:DEBUG:...passed.
> > >
> > > > DHCP: address
> > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > > DEBUG:DEBUG:...failed.
> > >
> > > > DHCP: route
> > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > > DEBUG:DEBUG:...failed.
> > >
> > > > DHCP: MTU
> > > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > > DEBUG:DEBUG:...failed.
> > >
> > > > DHCPv6: address
> > > DEBUG:
> >
> > Thanks, so it's the issue David recently mentioned with
> > dhclient-script(8) being prevented by SELinux from setting up addresses
> > and routes via ip(8), even though it's in a detached namespace and that
> > should be allowed.
> >
> > We should probably add something like we do in contrib/selinux/pasta.te
> > to https://github.com/fedora-selinux/selinux-policy:
> >
> >   roleattribute user_r usernetctl_roles;
> >   role usernetctl_roles types <whatever dhclient runs as>;
> >
> > Now, we can disable SELinux temporarily to run tests, but eventually
> > we'll want to have tests with DHCP clients in unprivileged setups also
> > as part of Fedora automated tests, and I'm fairly sure that those run
> > with SELinux in enforcing mode. So we should really fix this.
>
> Sure, I will file a ticket for that.
> >
> > By the way, it would also be interesting to see if, once the test suite
> > gets past this point, you get further messages in audit.log.
> >
> > If you do 'setenforce 0', SELinux switches to the so-called "complain
> > mode", and warnings are still logged, but they won't block anything.
> >
> > So, with 'setenforce 0', we can find out from audit.log if we would hit
> > further failures.
>
> Here is the audit.log:
>
> https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb

Sorry for the wrong link.  Attached the log.
>
> From what I can see, there is no 'avc:  denied' after the dhcp cases.
>
> >
> > Maybe also relevant:
> >
> >   https://github.com/fedora-selinux/selinux-policy/pull/1838
> >
> > ...but it's not being merged for some reason.
> >
> > --
> > Stefano
> >
>
>
> --
> Thanks,
>
> Yumei Huang



-- 
Thanks,

Yumei Huang

[-- Attachment #2: audit.log --]
[-- Type: text/x-log, Size: 12624 bytes --]

    type=AVC msg=audit(1758607564.171:14359): avc:  denied  { append } for  pid=3229241 comm="dhclient" path="/tmp/passt-tests-HbjFSR/pasta/context_ns.stdout.0UOHzZBw" dev="tmpfs" ino=120034 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=fifo_file permissive=1
    type=AVC msg=audit(1758607564.174:14360): avc:  denied  { dac_override } for  pid=3229242 comm="dhclient" capability=1  scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=cap_userns permissive=1
    type=AVC msg=audit(1758607564.176:14361): avc:  denied  { ioctl } for  pid=3229245 comm="dhclient-script" path="/tmp/passt-tests-HbjFSR/pasta/context_ns.stderr.xIrFAMG9" dev="tmpfs" ino=120035 ioctlcmd=0x540f scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=fifo_file permissive=1
    type=AVC msg=audit(1758607564.177:14362): avc:  denied  { dac_read_search } for  pid=3229245 comm="dhclient-script" capability=2  scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=cap_userns permissive=1
    type=AVC msg=audit(1758607564.183:14363): avc:  denied  { net_admin } for  pid=3229249 comm="ip" capability=12  scontext=unconfined_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:ifconfig_t:s0-s0:c0.c1023 tclass=cap_userns permissive=1
    type=AVC msg=audit(1758607564.184:14364): avc:  denied  { net_raw } for  pid=3229242 comm="dhclient" capability=13  scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tclass=cap_userns permissive=1
    type=AVC msg=audit(1758607564.203:14365): avc:  denied  { net_raw } for  pid=3229256 comm="arping" capability=13  scontext=unconfined_u:system_r:netutils_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:netutils_t:s0-s0:c0.c1023 tclass=cap_userns permissive=1
    type=AVC msg=audit(1758607569.463:14366): avc:  denied  { ioctl } for  pid=3230417 comm="dhclient-script" path="/tmp/passt-tests-HbjFSR/pasta/context_ns.stderr.xiplKRwD" dev="tmpfs" ino=120047 ioctlcmd=0x540f scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=fifo_file permissive=1
    type=SERVICE_STOP msg=audit(1758607587.938:14367): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758607587.991:14368): prog-id=608 op=UNLOAD
    type=BPF msg=audit(1758607601.824:14369): prog-id=610 op=UNLOAD
    type=BPF msg=audit(1758607601.824:14370): prog-id=609 op=UNLOAD
    type=BPF msg=audit(1758607601.843:14371): prog-id=611 op=LOAD
    type=BPF msg=audit(1758607601.844:14372): prog-id=612 op=LOAD
    type=BPF msg=audit(1758607601.844:14373): prog-id=613 op=LOAD
    type=SERVICE_START msg=audit(1758607601.892:14374): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758607658.083:14375): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758607658.136:14376): prog-id=611 op=UNLOAD
    type=BPF msg=audit(1758607676.707:14377): prog-id=613 op=UNLOAD
    type=BPF msg=audit(1758607676.707:14378): prog-id=612 op=UNLOAD
    type=BPF msg=audit(1758607676.722:14379): prog-id=614 op=LOAD
    type=BPF msg=audit(1758607676.723:14380): prog-id=615 op=LOAD
    type=BPF msg=audit(1758607676.723:14381): prog-id=616 op=LOAD
    type=SERVICE_START msg=audit(1758607676.771:14382): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758607706.808:14383): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758607706.852:14384): prog-id=614 op=UNLOAD
    type=BPF msg=audit(1758607783.182:14385): prog-id=616 op=UNLOAD
    type=BPF msg=audit(1758607783.182:14386): prog-id=615 op=UNLOAD
    type=BPF msg=audit(1758607783.202:14387): prog-id=617 op=LOAD
    type=BPF msg=audit(1758607783.203:14388): prog-id=618 op=LOAD
    type=BPF msg=audit(1758607783.203:14389): prog-id=619 op=LOAD
    type=SERVICE_START msg=audit(1758607783.249:14390): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758607813.285:14391): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758607813.331:14392): prog-id=617 op=UNLOAD
    type=BPF msg=audit(1758607853.680:14393): prog-id=619 op=UNLOAD
    type=BPF msg=audit(1758607853.680:14394): prog-id=618 op=UNLOAD
    type=BPF msg=audit(1758607853.684:14395): prog-id=620 op=LOAD
    type=BPF msg=audit(1758607853.684:14396): prog-id=621 op=LOAD
    type=BPF msg=audit(1758607853.685:14397): prog-id=622 op=LOAD
    type=SERVICE_START msg=audit(1758607853.729:14398): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758607883.766:14399): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758607883.814:14400): prog-id=620 op=UNLOAD
    type=BPF msg=audit(1758608022.969:14401): prog-id=622 op=UNLOAD
    type=BPF msg=audit(1758608022.969:14402): prog-id=621 op=UNLOAD
    type=BPF msg=audit(1758608022.984:14403): prog-id=623 op=LOAD
    type=BPF msg=audit(1758608022.984:14404): prog-id=624 op=LOAD
    type=BPF msg=audit(1758608022.985:14405): prog-id=625 op=LOAD
    type=SERVICE_START msg=audit(1758608023.032:14406): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758608053.070:14407): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758608053.124:14408): prog-id=623 op=UNLOAD
    type=BPF msg=audit(1758608053.682:14409): prog-id=625 op=UNLOAD
    type=BPF msg=audit(1758608053.682:14410): prog-id=624 op=UNLOAD
    type=BPF msg=audit(1758608053.696:14411): prog-id=626 op=LOAD
    type=BPF msg=audit(1758608053.697:14412): prog-id=627 op=LOAD
    type=BPF msg=audit(1758608053.697:14413): prog-id=628 op=LOAD
    type=SERVICE_START msg=audit(1758608053.739:14414): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758608083.776:14415): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758608083.828:14416): prog-id=626 op=UNLOAD
    type=BPF msg=audit(1758608211.184:14417): prog-id=628 op=UNLOAD
    type=BPF msg=audit(1758608211.184:14418): prog-id=627 op=UNLOAD
    type=BPF msg=audit(1758608211.197:14419): prog-id=629 op=LOAD
    type=BPF msg=audit(1758608211.197:14420): prog-id=630 op=LOAD
    type=BPF msg=audit(1758608211.197:14421): prog-id=631 op=LOAD
    type=SERVICE_START msg=audit(1758608211.244:14422): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758608241.286:14423): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758608241.342:14424): prog-id=629 op=UNLOAD
    type=BPF msg=audit(1758608243.879:14425): prog-id=631 op=UNLOAD
    type=BPF msg=audit(1758608243.879:14426): prog-id=630 op=UNLOAD
    type=BPF msg=audit(1758608243.897:14427): prog-id=632 op=LOAD
    type=BPF msg=audit(1758608243.897:14428): prog-id=633 op=LOAD
    type=BPF msg=audit(1758608243.898:14429): prog-id=634 op=LOAD
    type=SERVICE_START msg=audit(1758608243.945:14430): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758608532.228:14431): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758608532.276:14432): prog-id=632 op=UNLOAD
    type=BPF msg=audit(1758608533.627:14433): prog-id=634 op=UNLOAD
    type=BPF msg=audit(1758608533.627:14434): prog-id=633 op=UNLOAD
    type=BPF msg=audit(1758608533.641:14435): prog-id=635 op=LOAD
    type=BPF msg=audit(1758608533.642:14436): prog-id=636 op=LOAD
    type=BPF msg=audit(1758608533.642:14437): prog-id=637 op=LOAD
    type=SERVICE_START msg=audit(1758608533.685:14438): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758608563.722:14439): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758608563.776:14440): prog-id=635 op=UNLOAD
    type=SERVICE_START msg=audit(1758608676.825:14441): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758608676.825:14442): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758608995.196:14443): prog-id=637 op=UNLOAD
    type=BPF msg=audit(1758608995.196:14444): prog-id=636 op=UNLOAD
    type=BPF msg=audit(1758608995.221:14445): prog-id=638 op=LOAD
    type=BPF msg=audit(1758608995.222:14446): prog-id=639 op=LOAD
    type=BPF msg=audit(1758608995.222:14447): prog-id=640 op=LOAD
    type=SERVICE_START msg=audit(1758608995.270:14448): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=SERVICE_STOP msg=audit(1758609025.308:14449): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
    type=BPF msg=audit(1758609025.362:14450): prog-id=638 op=UNLOAD

Re: [PATCH] test: Update README.md

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]

On Fri, Sep 19, 2025 at 11:58:22AM +0200, Stefano Brivio wrote:
> On Fri, 19 Sep 2025 09:43:29 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
> 
> > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > ---
> >  test/README.md | 31 +++++++++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> > 
> > diff --git a/test/README.md b/test/README.md
> > index 91ca603..e3e9d37 100644
> > --- a/test/README.md
> > +++ b/test/README.md
> > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > +    sipcalc socat strace tmux uidmap valgrind
> >  
> >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> >  
> >  ## Regular test
> >  
> > -Just issue:
> > +Before running the tests, you need to prepare the required assets:
> > +
> > +    cd test
> > +    make assets
> > +
> > +Then issue:
> >  
> >      ./run
> >  
> > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> >  
> >      PCAP=1 TRACE=1 ./run
> >  
> > +**Note:**
> > +
> > +* It's recommended to run the commands as a non-root user.
> > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> 
> Thanks for the research, I wasn't aware of that, and recently spent
> quite some time figuring that out (for other reasons):
> 
>   https://issues.redhat.com/browse/RHEL-70222
> 
> in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> with 'machinectl shell' instead.
> 
> At the same time: running this whole stuff as root sounds rather crazy,
> unless it's a throw-away VMs with absolutely nothing important on it.

That might be more common than us old-school Unix heads tend to think.

> That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> make the wording stronger, something like:
> 
> * Don't run the tests as root, it's not needed!
> * If you really need to, note that ...

Right.  The whole point of passt/pasta is not to require root, so
testing it as root means you're not really testing what it's intended
to do.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] test: Update README.md

[Stefano Brivio]

On Tue, 23 Sep 2025 14:36:41 +0800
Yumei Huang <yuhuang@redhat.com> wrote:

> On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Mon, 22 Sep 2025 11:03:23 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >  
> > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > >
> > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > >  
> > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > ---
> > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/test/README.md b/test/README.md
> > > > > index 91ca603..e3e9d37 100644
> > > > > --- a/test/README.md
> > > > > +++ b/test/README.md
> > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > >
> > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > >
> > > > >  ## Regular test
> > > > >
> > > > > -Just issue:
> > > > > +Before running the tests, you need to prepare the required assets:
> > > > > +
> > > > > +    cd test
> > > > > +    make assets
> > > > > +
> > > > > +Then issue:
> > > > >
> > > > >      ./run
> > > > >
> > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > >
> > > > >      PCAP=1 TRACE=1 ./run
> > > > >
> > > > > +**Note:**
> > > > > +
> > > > > +* It's recommended to run the commands as a non-root user.
> > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.  
> > > >
> > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > quite some time figuring that out (for other reasons):
> > > >
> > > >   https://issues.redhat.com/browse/RHEL-70222
> > > >
> > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > with 'machinectl shell' instead.
> > > >
> > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > >
> > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > make the wording stronger, something like:
> > > >
> > > > * Don't run the tests as root, it's not needed!
> > > > * If you really need to, note that ...
> > > >  
> > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > +  correct runtime directory is set up.  
> > > >
> > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > whatever reason.  
> > >
> > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > running 'make assets',
> > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.  
> >
> > Ah, I didn't know! So this is actually similar to
> > https://issues.redhat.com/browse/RHEL-70222.
> >  
> > > If we run 'make assets' with root, the error is like this:
> > >
> > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > libguestfs: error: could not create appliance through libvirt.
> > > Original error from libvirt: Cannot access storage file
> > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > >
> > > If we switch to a non-root user via 'su', the error is like this:
> > >
> > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > '/run/user/0/libvirt': Permission denied
> > > libguestfs: error: could not connect to libvirt (URI =
> > > qemu:///session): Cannot create user runtime directory
> > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > >
> > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > exact cmd here? I tried this, seems not work.
> > >
> > >     # machinectl shell --uid=$(id -u pat) .host
> > > /home/test/passt/test/make assets
> > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > >
> > >     Connection to the local host terminated.  
> >
> > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > replacement), that is:
> >
> >     $ machinectl shell
> >     # make assets
> >
> > ...because that one will set XDG_RUNTIME_DIR.  
> 
> Yes, 'machinectl shell' will solve the issue when switching to a
> non-root user via su. But it doesn't solve the issue when running
> 'make assets' as root. They are actually different issues as above.

Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
Does that work?

> Maybe we can just put it like:
> 
>     Running the commands as root is just not allowed.  If you login
> the system with root, don't use su to switch users due to [Bug
> 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> and log back in as the intended user, or use 'machinectl shell
> --uid=$user'.
> 
> What do you think?

Well, it's free software, so "not allowed" doesn't really mean much.

I would simply warn users that it's a bad idea and it's not needed,
something like my previous proposal:

  * Don't run the tests as root, it's not needed!
  * If you really need to, note that ...

and then just list the workaround that actually works.

I think the most typical need for running things as root is that you
don't actually have other users (it happens with some VM images or
in embedded systems), so 'machinectl shell --uid=$user' won't really
help there.

Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropriate
(does /tmp work?)?

> > > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > > +  temporarily disable it by running:
> > > > > +
> > > > > +        setenforce 0  
> > > >
> > > > By the way, other than the DHCP client not working on Fedora in a
> > > > namespace (which we should really fix, I can look into it if you share
> > > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > > any other issue with it?
> > > >  
> > >
> > > Sure, I will send you a link containing the audit.log.
> > > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > > :address'. Looks like an endless loop there. So except the very first
> > > few tests, other tests haven't been executed.
> > >
> > > === pasta/dhcp  
> > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>  
> > > Interface name
> > > DEBUG:DEBUG:? [ -n "eno8303" ]
> > > DEBUG:DEBUG:...passed.
> > >  
> > > > DHCP: address  
> > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > > DEBUG:DEBUG:...failed.
> > >  
> > > > DHCP: route  
> > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > > DEBUG:DEBUG:...failed.
> > >  
> > > > DHCP: MTU  
> > > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > > DEBUG:DEBUG:...failed.
> > >  
> > > > DHCPv6: address  
> > > DEBUG:  
> >
> > Thanks, so it's the issue David recently mentioned with
> > dhclient-script(8) being prevented by SELinux from setting up addresses
> > and routes via ip(8), even though it's in a detached namespace and that
> > should be allowed.
> >
> > We should probably add something like we do in contrib/selinux/pasta.te
> > to https://github.com/fedora-selinux/selinux-policy:
> >
> >   roleattribute user_r usernetctl_roles;
> >   role usernetctl_roles types <whatever dhclient runs as>;
> >
> > Now, we can disable SELinux temporarily to run tests, but eventually
> > we'll want to have tests with DHCP clients in unprivileged setups also
> > as part of Fedora automated tests, and I'm fairly sure that those run
> > with SELinux in enforcing mode. So we should really fix this.  
> 
> Sure, I will file a ticket for that.

Thanks. Note that it's not a ticket for passt, it's maybe a ticket for
fedora-selinux, but I'm not sure if it's really helpful to file issues
there. I guess we should try things out and send a merge request.

> > By the way, it would also be interesting to see if, once the test suite
> > gets past this point, you get further messages in audit.log.
> >
> > If you do 'setenforce 0', SELinux switches to the so-called "complain
> > mode", and warnings are still logged, but they won't block anything.
> >
> > So, with 'setenforce 0', we can find out from audit.log if we would hit
> > further failures.  
> 
> Here is the audit.log:
> 
> https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb
>
> From what I can see, there is no 'avc:  denied' after the dhcp cases.

[looking at log you attached later] great, I don't see other issues
either! So it seems to be just that, and then we'll be able to run
tests on Fedora-like distributions with SELinux enabled.

-- 
Stefano

Re: [PATCH] test: Update README.md

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 7631 bytes --]

On Tue, Sep 23, 2025 at 12:32:13PM +0200, Stefano Brivio wrote:
> On Tue, 23 Sep 2025 14:36:41 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
> 
> > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> > >
> > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > Yumei Huang <yuhuang@redhat.com> wrote:
> > >  
> > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > > >
> > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > >  
> > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > ---
> > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > index 91ca603..e3e9d37 100644
> > > > > > --- a/test/README.md
> > > > > > +++ b/test/README.md
> > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > >
> > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > >
> > > > > >  ## Regular test
> > > > > >
> > > > > > -Just issue:
> > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > +
> > > > > > +    cd test
> > > > > > +    make assets
> > > > > > +
> > > > > > +Then issue:
> > > > > >
> > > > > >      ./run
> > > > > >
> > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > >
> > > > > >      PCAP=1 TRACE=1 ./run
> > > > > >
> > > > > > +**Note:**
> > > > > > +
> > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.  
> > > > >
> > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > quite some time figuring that out (for other reasons):
> > > > >
> > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > >
> > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > with 'machinectl shell' instead.
> > > > >
> > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > >
> > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > make the wording stronger, something like:
> > > > >
> > > > > * Don't run the tests as root, it's not needed!
> > > > > * If you really need to, note that ...
> > > > >  
> > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > +  correct runtime directory is set up.  
> > > > >
> > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > whatever reason.  
> > > >
> > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > running 'make assets',
> > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.  
> > >
> > > Ah, I didn't know! So this is actually similar to
> > > https://issues.redhat.com/browse/RHEL-70222.
> > >  
> > > > If we run 'make assets' with root, the error is like this:
> > > >
> > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > libguestfs: error: could not create appliance through libvirt.
> > > > Original error from libvirt: Cannot access storage file
> > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > >
> > > > If we switch to a non-root user via 'su', the error is like this:
> > > >
> > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > '/run/user/0/libvirt': Permission denied
> > > > libguestfs: error: could not connect to libvirt (URI =
> > > > qemu:///session): Cannot create user runtime directory
> > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > >
> > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > exact cmd here? I tried this, seems not work.
> > > >
> > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > /home/test/passt/test/make assets
> > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > >
> > > >     Connection to the local host terminated.  
> > >
> > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > replacement), that is:
> > >
> > >     $ machinectl shell
> > >     # make assets
> > >
> > > ...because that one will set XDG_RUNTIME_DIR.  
> > 
> > Yes, 'machinectl shell' will solve the issue when switching to a
> > non-root user via su. But it doesn't solve the issue when running
> > 'make assets' as root. They are actually different issues as above.
> 
> Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> Does that work?
> 
> > Maybe we can just put it like:
> > 
> >     Running the commands as root is just not allowed.  If you login
> > the system with root, don't use su to switch users due to [Bug
> > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > and log back in as the intended user, or use 'machinectl shell
> > --uid=$user'.
> > 
> > What do you think?
> 
> Well, it's free software, so "not allowed" doesn't really mean much.
> 
> I would simply warn users that it's a bad idea and it's not needed,
> something like my previous proposal:
> 
>   * Don't run the tests as root, it's not needed!
>   * If you really need to, note that ...
> 
> and then just list the workaround that actually works.
> 
> I think the most typical need for running things as root is that you
> don't actually have other users (it happens with some VM images or
> in embedded systems), so 'machinectl shell --uid=$user' won't really
> help there.
> 
> Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropriate
> (does /tmp work?)?

I wonder if we're overcomplicating things.  The README doesn't need to
address every possible option, just the common / expected ones.  So I
think it's sufficient to say "don't test as root, the whole point of
passt is not to run as root".  If you insist on testing as root you
can figure out the details yourself.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] test: Update README.md

[Yumei Huang]

On Tue, Sep 23, 2025 at 6:32 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Tue, 23 Sep 2025 14:36:41 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
>
> > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> > >
> > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > Yumei Huang <yuhuang@redhat.com> wrote:
> > >
> > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > > >
> > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > >
> > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > ---
> > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > index 91ca603..e3e9d37 100644
> > > > > > --- a/test/README.md
> > > > > > +++ b/test/README.md
> > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > >
> > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > >
> > > > > >  ## Regular test
> > > > > >
> > > > > > -Just issue:
> > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > +
> > > > > > +    cd test
> > > > > > +    make assets
> > > > > > +
> > > > > > +Then issue:
> > > > > >
> > > > > >      ./run
> > > > > >
> > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > >
> > > > > >      PCAP=1 TRACE=1 ./run
> > > > > >
> > > > > > +**Note:**
> > > > > > +
> > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> > > > >
> > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > quite some time figuring that out (for other reasons):
> > > > >
> > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > >
> > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > with 'machinectl shell' instead.
> > > > >
> > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > >
> > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > make the wording stronger, something like:
> > > > >
> > > > > * Don't run the tests as root, it's not needed!
> > > > > * If you really need to, note that ...
> > > > >
> > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > +  correct runtime directory is set up.
> > > > >
> > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > whatever reason.
> > > >
> > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > running 'make assets',
> > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.
> > >
> > > Ah, I didn't know! So this is actually similar to
> > > https://issues.redhat.com/browse/RHEL-70222.
> > >
> > > > If we run 'make assets' with root, the error is like this:
> > > >
> > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > libguestfs: error: could not create appliance through libvirt.
> > > > Original error from libvirt: Cannot access storage file
> > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > >
> > > > If we switch to a non-root user via 'su', the error is like this:
> > > >
> > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > '/run/user/0/libvirt': Permission denied
> > > > libguestfs: error: could not connect to libvirt (URI =
> > > > qemu:///session): Cannot create user runtime directory
> > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > >
> > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > exact cmd here? I tried this, seems not work.
> > > >
> > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > /home/test/passt/test/make assets
> > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > >
> > > >     Connection to the local host terminated.
> > >
> > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > replacement), that is:
> > >
> > >     $ machinectl shell
> > >     # make assets
> > >
> > > ...because that one will set XDG_RUNTIME_DIR.
> >
> > Yes, 'machinectl shell' will solve the issue when switching to a
> > non-root user via su. But it doesn't solve the issue when running
> > 'make assets' as root. They are actually different issues as above.
>
> Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> Does that work?

I guess I need to clarify the issues more clearly.

a) If we login the system with the non-root user, `/run/user/ID` is
created and XDG_RUNTIME_DIR is pointing to that correctly. So 'make
assets' works well.

b) If we login the system with root, then switch to a non-root user
via 'su', 'make assets' fails due to Bug 967509. XDG_RUNTIME_DIR is
not reset and points to /run/user/(ID of the previous user), which is
/run/user/0.

    libguestfs: error: could not connect to libvirt (URI =
qemu:///session): Cannot create user runtime directory
'/run/user/0/libvirt': Permission denied [code=38 int1=13]

Switching the user with 'machinectl shell --uid=$user' can solve the issue.

c) If we run 'make assets' as root, (no matter we just login with
root, or switch to root via su or machinectl shell), 'make assets'
always fails with a different error.

    libguestfs: error: could not create appliance through libvirt.
Original error from libvirt: Cannot access storage file
'/home/pat/tmp/t5-passt/test/prepared-debian-10-nocloud-amd64.qcow2'
(as uid:107, gid:107): Permission denied [code=38 int1=13]

The XDG_RUNTIME_DIR is no longer an issue, since root can access every
directory under /run/user. I guess the problem here is that we just
can't run 'virsh edit' as root.

>
> > Maybe we can just put it like:
> >
> >     Running the commands as root is just not allowed.  If you login
> > the system with root, don't use su to switch users due to [Bug
> > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > and log back in as the intended user, or use 'machinectl shell
> > --uid=$user'.
> >
> > What do you think?
>
> Well, it's free software, so "not allowed" doesn't really mean much.
>
> I would simply warn users that it's a bad idea and it's not needed,
> something like my previous proposal:
>
>   * Don't run the tests as root, it's not needed!
>   * If you really need to, note that ...
>
> and then just list the workaround that actually works.
>
> I think the most typical need for running things as root is that you
> don't actually have other users (it happens with some VM images or
> in embedded systems), so 'machinectl shell --uid=$user' won't really
> help there.

Well, I have to admit that I usually do everything with root on my
test machines. And I don't see a solution/workaround to fix the issue
when running 'make assets' as root as c). The workaround proposed is
just for those who login with root and switch to a non-root user to
run the tests.

>
> Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropriate
> (does /tmp work?)?
>
> > > > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > > > +  temporarily disable it by running:
> > > > > > +
> > > > > > +        setenforce 0
> > > > >
> > > > > By the way, other than the DHCP client not working on Fedora in a
> > > > > namespace (which we should really fix, I can look into it if you share
> > > > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > > > any other issue with it?
> > > > >
> > > >
> > > > Sure, I will send you a link containing the audit.log.
> > > > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > > > :address'. Looks like an endless loop there. So except the very first
> > > > few tests, other tests haven't been executed.
> > > >
> > > > === pasta/dhcp
> > > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>
> > > > Interface name
> > > > DEBUG:DEBUG:? [ -n "eno8303" ]
> > > > DEBUG:DEBUG:...passed.
> > > >
> > > > > DHCP: address
> > > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > > > DEBUG:DEBUG:...failed.
> > > >
> > > > > DHCP: route
> > > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > > > DEBUG:DEBUG:...failed.
> > > >
> > > > > DHCP: MTU
> > > > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > > > DEBUG:DEBUG:...failed.
> > > >
> > > > > DHCPv6: address
> > > > DEBUG:
> > >
> > > Thanks, so it's the issue David recently mentioned with
> > > dhclient-script(8) being prevented by SELinux from setting up addresses
> > > and routes via ip(8), even though it's in a detached namespace and that
> > > should be allowed.
> > >
> > > We should probably add something like we do in contrib/selinux/pasta.te
> > > to https://github.com/fedora-selinux/selinux-policy:
> > >
> > >   roleattribute user_r usernetctl_roles;
> > >   role usernetctl_roles types <whatever dhclient runs as>;
> > >
> > > Now, we can disable SELinux temporarily to run tests, but eventually
> > > we'll want to have tests with DHCP clients in unprivileged setups also
> > > as part of Fedora automated tests, and I'm fairly sure that those run
> > > with SELinux in enforcing mode. So we should really fix this.
> >
> > Sure, I will file a ticket for that.
>
> Thanks. Note that it's not a ticket for passt, it's maybe a ticket for
> fedora-selinux, but I'm not sure if it's really helpful to file issues
> there. I guess we should try things out and send a merge request.
Agree. Let's just disable it temporarily to bypass the issue.
>
> > > By the way, it would also be interesting to see if, once the test suite
> > > gets past this point, you get further messages in audit.log.
> > >
> > > If you do 'setenforce 0', SELinux switches to the so-called "complain
> > > mode", and warnings are still logged, but they won't block anything.
> > >
> > > So, with 'setenforce 0', we can find out from audit.log if we would hit
> > > further failures.
> >
> > Here is the audit.log:
> >
> > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb
> >
> > From what I can see, there is no 'avc:  denied' after the dhcp cases.
>
> [looking at log you attached later] great, I don't see other issues
> either! So it seems to be just that, and then we'll be able to run
> tests on Fedora-like distributions with SELinux enabled.
>
> --
> Stefano
>


-- 
Thanks,

Yumei Huang

Re: [PATCH] test: Update README.md

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 9804 bytes --]

On Wed, Sep 24, 2025 at 09:58:57AM +0800, Yumei Huang wrote:
> On Tue, Sep 23, 2025 at 6:32 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Tue, 23 Sep 2025 14:36:41 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >
> > > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > >
> > > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > >
> > > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > > > >
> > > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > > >
> > > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > > ---
> > > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > > index 91ca603..e3e9d37 100644
> > > > > > > --- a/test/README.md
> > > > > > > +++ b/test/README.md
> > > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > > >
> > > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > > >
> > > > > > >  ## Regular test
> > > > > > >
> > > > > > > -Just issue:
> > > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > > +
> > > > > > > +    cd test
> > > > > > > +    make assets
> > > > > > > +
> > > > > > > +Then issue:
> > > > > > >
> > > > > > >      ./run
> > > > > > >
> > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > > >
> > > > > > >      PCAP=1 TRACE=1 ./run
> > > > > > >
> > > > > > > +**Note:**
> > > > > > > +
> > > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> > > > > >
> > > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > > quite some time figuring that out (for other reasons):
> > > > > >
> > > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > > >
> > > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > > with 'machinectl shell' instead.
> > > > > >
> > > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > > >
> > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > > make the wording stronger, something like:
> > > > > >
> > > > > > * Don't run the tests as root, it's not needed!
> > > > > > * If you really need to, note that ...
> > > > > >
> > > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > > +  correct runtime directory is set up.
> > > > > >
> > > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > > whatever reason.
> > > > >
> > > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > > running 'make assets',
> > > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.
> > > >
> > > > Ah, I didn't know! So this is actually similar to
> > > > https://issues.redhat.com/browse/RHEL-70222.
> > > >
> > > > > If we run 'make assets' with root, the error is like this:
> > > > >
> > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > libguestfs: error: could not create appliance through libvirt.
> > > > > Original error from libvirt: Cannot access storage file
> > > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > > >
> > > > > If we switch to a non-root user via 'su', the error is like this:
> > > > >
> > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > > '/run/user/0/libvirt': Permission denied
> > > > > libguestfs: error: could not connect to libvirt (URI =
> > > > > qemu:///session): Cannot create user runtime directory
> > > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > > >
> > > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > > exact cmd here? I tried this, seems not work.
> > > > >
> > > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > > /home/test/passt/test/make assets
> > > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > > >
> > > > >     Connection to the local host terminated.
> > > >
> > > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > > replacement), that is:
> > > >
> > > >     $ machinectl shell
> > > >     # make assets
> > > >
> > > > ...because that one will set XDG_RUNTIME_DIR.
> > >
> > > Yes, 'machinectl shell' will solve the issue when switching to a
> > > non-root user via su. But it doesn't solve the issue when running
> > > 'make assets' as root. They are actually different issues as above.
> >
> > Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> > Does that work?
> 
> I guess I need to clarify the issues more clearly.
> 
> a) If we login the system with the non-root user, `/run/user/ID` is
> created and XDG_RUNTIME_DIR is pointing to that correctly. So 'make
> assets' works well.
> 
> b) If we login the system with root, then switch to a non-root user
> via 'su', 'make assets' fails due to Bug 967509. XDG_RUNTIME_DIR is
> not reset and points to /run/user/(ID of the previous user), which is
> /run/user/0.
> 
>     libguestfs: error: could not connect to libvirt (URI =
> qemu:///session): Cannot create user runtime directory
> '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> 
> Switching the user with 'machinectl shell --uid=$user' can solve the issue.
> 
> c) If we run 'make assets' as root, (no matter we just login with
> root, or switch to root via su or machinectl shell), 'make assets'
> always fails with a different error.
> 
>     libguestfs: error: could not create appliance through libvirt.
> Original error from libvirt: Cannot access storage file
> '/home/pat/tmp/t5-passt/test/prepared-debian-10-nocloud-amd64.qcow2'
> (as uid:107, gid:107): Permission denied [code=38 int1=13]
> 
> The XDG_RUNTIME_DIR is no longer an issue, since root can access every
> directory under /run/user. I guess the problem here is that we just
> can't run 'virsh edit' as root.

I'm guessing the problem here is that something in the libguestfs -> libvirt
-> whatever chain is dropping capabilities, so it no longer has
permission to everything.  Or if the home directory there is mounted
via NFS or something, there can be root doesn't actually have
permission to everything.

> >
> > > Maybe we can just put it like:
> > >
> > >     Running the commands as root is just not allowed.  If you login
> > > the system with root, don't use su to switch users due to [Bug
> > > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > > and log back in as the intended user, or use 'machinectl shell
> > > --uid=$user'.
> > >
> > > What do you think?
> >
> > Well, it's free software, so "not allowed" doesn't really mean much.
> >
> > I would simply warn users that it's a bad idea and it's not needed,
> > something like my previous proposal:
> >
> >   * Don't run the tests as root, it's not needed!
> >   * If you really need to, note that ...
> >
> > and then just list the workaround that actually works.
> >
> > I think the most typical need for running things as root is that you
> > don't actually have other users (it happens with some VM images or
> > in embedded systems), so 'machinectl shell --uid=$user' won't really
> > help there.
> 
> Well, I have to admit that I usually do everything with root on my
> test machines. And I don't see a solution/workaround to fix the issue
> when running 'make assets' as root as c). The workaround proposed is
> just for those who login with root and switch to a non-root user to
> run the tests.

For many sorts of tests on throwaway machines, that's pretty
reasonable.  Testing passt we specifically want to test that it
operates as non-root, so I'd suggest you tweak your procedures for
grabbing a test machine so that you routinely create a user.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] test: Update README.md

[Yumei Huang]

On Wed, Sep 24, 2025 at 11:44 AM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Wed, Sep 24, 2025 at 09:58:57AM +0800, Yumei Huang wrote:
> > On Tue, Sep 23, 2025 at 6:32 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > >
> > > On Tue, 23 Sep 2025 14:36:41 +0800
> > > Yumei Huang <yuhuang@redhat.com> wrote:
> > >
> > > > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > > >
> > > > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > >
> > > > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > > > > >
> > > > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > > > >
> > > > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > > > ---
> > > > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > > > index 91ca603..e3e9d37 100644
> > > > > > > > --- a/test/README.md
> > > > > > > > +++ b/test/README.md
> > > > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > > > >
> > > > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > > > >
> > > > > > > >  ## Regular test
> > > > > > > >
> > > > > > > > -Just issue:
> > > > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > > > +
> > > > > > > > +    cd test
> > > > > > > > +    make assets
> > > > > > > > +
> > > > > > > > +Then issue:
> > > > > > > >
> > > > > > > >      ./run
> > > > > > > >
> > > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > > > >
> > > > > > > >      PCAP=1 TRACE=1 ./run
> > > > > > > >
> > > > > > > > +**Note:**
> > > > > > > > +
> > > > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.
> > > > > > >
> > > > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > > > quite some time figuring that out (for other reasons):
> > > > > > >
> > > > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > > > >
> > > > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > > > with 'machinectl shell' instead.
> > > > > > >
> > > > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > > > >
> > > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > > > make the wording stronger, something like:
> > > > > > >
> > > > > > > * Don't run the tests as root, it's not needed!
> > > > > > > * If you really need to, note that ...
> > > > > > >
> > > > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > > > +  correct runtime directory is set up.
> > > > > > >
> > > > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > > > whatever reason.
> > > > > >
> > > > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > > > running 'make assets',
> > > > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.
> > > > >
> > > > > Ah, I didn't know! So this is actually similar to
> > > > > https://issues.redhat.com/browse/RHEL-70222.
> > > > >
> > > > > > If we run 'make assets' with root, the error is like this:
> > > > > >
> > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > > libguestfs: error: could not create appliance through libvirt.
> > > > > > Original error from libvirt: Cannot access storage file
> > > > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > > > >
> > > > > > If we switch to a non-root user via 'su', the error is like this:
> > > > > >
> > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > > > '/run/user/0/libvirt': Permission denied
> > > > > > libguestfs: error: could not connect to libvirt (URI =
> > > > > > qemu:///session): Cannot create user runtime directory
> > > > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > > > >
> > > > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > > > exact cmd here? I tried this, seems not work.
> > > > > >
> > > > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > > > /home/test/passt/test/make assets
> > > > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > > > >
> > > > > >     Connection to the local host terminated.
> > > > >
> > > > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > > > replacement), that is:
> > > > >
> > > > >     $ machinectl shell
> > > > >     # make assets
> > > > >
> > > > > ...because that one will set XDG_RUNTIME_DIR.
> > > >
> > > > Yes, 'machinectl shell' will solve the issue when switching to a
> > > > non-root user via su. But it doesn't solve the issue when running
> > > > 'make assets' as root. They are actually different issues as above.
> > >
> > > Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> > > Does that work?
> >
> > I guess I need to clarify the issues more clearly.
> >
> > a) If we login the system with the non-root user, `/run/user/ID` is
> > created and XDG_RUNTIME_DIR is pointing to that correctly. So 'make
> > assets' works well.
> >
> > b) If we login the system with root, then switch to a non-root user
> > via 'su', 'make assets' fails due to Bug 967509. XDG_RUNTIME_DIR is
> > not reset and points to /run/user/(ID of the previous user), which is
> > /run/user/0.
> >
> >     libguestfs: error: could not connect to libvirt (URI =
> > qemu:///session): Cannot create user runtime directory
> > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> >
> > Switching the user with 'machinectl shell --uid=$user' can solve the issue.
> >
> > c) If we run 'make assets' as root, (no matter we just login with
> > root, or switch to root via su or machinectl shell), 'make assets'
> > always fails with a different error.
> >
> >     libguestfs: error: could not create appliance through libvirt.
> > Original error from libvirt: Cannot access storage file
> > '/home/pat/tmp/t5-passt/test/prepared-debian-10-nocloud-amd64.qcow2'
> > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> >
> > The XDG_RUNTIME_DIR is no longer an issue, since root can access every
> > directory under /run/user. I guess the problem here is that we just
> > can't run 'virsh edit' as root.
>
> I'm guessing the problem here is that something in the libguestfs -> libvirt
> -> whatever chain is dropping capabilities, so it no longer has
> permission to everything.  Or if the home directory there is mounted
> via NFS or something, there can be root doesn't actually have
> permission to everything.

Yeah, probably. The workaround proposed is not for root. That's why I
couldn't proceed with:

    * Don't run the tests as root, it's not needed!
    * If you really need to, note that ...

>
> > >
> > > > Maybe we can just put it like:
> > > >
> > > >     Running the commands as root is just not allowed.  If you login
> > > > the system with root, don't use su to switch users due to [Bug
> > > > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > > > and log back in as the intended user, or use 'machinectl shell
> > > > --uid=$user'.
> > > >
> > > > What do you think?
> > >
> > > Well, it's free software, so "not allowed" doesn't really mean much.
> > >
> > > I would simply warn users that it's a bad idea and it's not needed,
> > > something like my previous proposal:
> > >
> > >   * Don't run the tests as root, it's not needed!
> > >   * If you really need to, note that ...
> > >
> > > and then just list the workaround that actually works.
> > >
> > > I think the most typical need for running things as root is that you
> > > don't actually have other users (it happens with some VM images or
> > > in embedded systems), so 'machinectl shell --uid=$user' won't really
> > > help there.
> >
> > Well, I have to admit that I usually do everything with root on my
> > test machines. And I don't see a solution/workaround to fix the issue
> > when running 'make assets' as root as c). The workaround proposed is
> > just for those who login with root and switch to a non-root user to
> > run the tests.
>
> For many sorts of tests on throwaway machines, that's pretty
> reasonable.  Testing passt we specifically want to test that it
> operates as non-root, so I'd suggest you tweak your procedures for
> grabbing a test machine so that you routinely create a user.
>

Thank you for the suggestion.  I've created a user for my test machine
and login with it every time so I don't hit more permission issues :D

> --
> David Gibson (he or they)       | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you, not the other way
>                                 | around.
> http://www.ozlabs.org/~dgibson



-- 
Thanks,

Yumei Huang

Re: [PATCH] test: Update README.md

[Stefano Brivio]

[Cc'ing Rich... Rich, see my first question below]

On Wed, 24 Sep 2025 09:58:57 +0800
Yumei Huang <yuhuang@redhat.com> wrote:

> On Tue, Sep 23, 2025 at 6:32 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Tue, 23 Sep 2025 14:36:41 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >  
> > > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > >
> > > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > >  
> > > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > > > >
> > > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > > >  
> > > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > > ---
> > > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > > index 91ca603..e3e9d37 100644
> > > > > > > --- a/test/README.md
> > > > > > > +++ b/test/README.md
> > > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > > >
> > > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > > >
> > > > > > >  ## Regular test
> > > > > > >
> > > > > > > -Just issue:
> > > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > > +
> > > > > > > +    cd test
> > > > > > > +    make assets
> > > > > > > +
> > > > > > > +Then issue:
> > > > > > >
> > > > > > >      ./run
> > > > > > >
> > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > > >
> > > > > > >      PCAP=1 TRACE=1 ./run
> > > > > > >
> > > > > > > +**Note:**
> > > > > > > +
> > > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.  
> > > > > >
> > > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > > quite some time figuring that out (for other reasons):
> > > > > >
> > > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > > >
> > > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > > with 'machinectl shell' instead.
> > > > > >
> > > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > > >
> > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > > make the wording stronger, something like:
> > > > > >
> > > > > > * Don't run the tests as root, it's not needed!
> > > > > > * If you really need to, note that ...
> > > > > >  
> > > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > > +  correct runtime directory is set up.  
> > > > > >
> > > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > > whatever reason.  
> > > > >
> > > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > > running 'make assets',
> > > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.  
> > > >
> > > > Ah, I didn't know! So this is actually similar to
> > > > https://issues.redhat.com/browse/RHEL-70222.
> > > >  
> > > > > If we run 'make assets' with root, the error is like this:
> > > > >
> > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > libguestfs: error: could not create appliance through libvirt.
> > > > > Original error from libvirt: Cannot access storage file
> > > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > > >
> > > > > If we switch to a non-root user via 'su', the error is like this:
> > > > >
> > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > > '/run/user/0/libvirt': Permission denied
> > > > > libguestfs: error: could not connect to libvirt (URI =
> > > > > qemu:///session): Cannot create user runtime directory
> > > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > > >
> > > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > > exact cmd here? I tried this, seems not work.
> > > > >
> > > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > > /home/test/passt/test/make assets
> > > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > > >
> > > > >     Connection to the local host terminated.  
> > > >
> > > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > > replacement), that is:
> > > >
> > > >     $ machinectl shell
> > > >     # make assets
> > > >
> > > > ...because that one will set XDG_RUNTIME_DIR.  
> > >
> > > Yes, 'machinectl shell' will solve the issue when switching to a
> > > non-root user via su. But it doesn't solve the issue when running
> > > 'make assets' as root. They are actually different issues as above.  
> >
> > Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> > Does that work?  
> 
> I guess I need to clarify the issues more clearly.
> 
> a) If we login the system with the non-root user, `/run/user/ID` is
> created and XDG_RUNTIME_DIR is pointing to that correctly. So 'make
> assets' works well.
> 
> b) If we login the system with root, then switch to a non-root user
> via 'su', 'make assets' fails due to Bug 967509. XDG_RUNTIME_DIR is
> not reset and points to /run/user/(ID of the previous user), which is
> /run/user/0.
> 
>     libguestfs: error: could not connect to libvirt (URI =
> qemu:///session): Cannot create user runtime directory
> '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> 
> Switching the user with 'machinectl shell --uid=$user' can solve the issue.
> 
> c) If we run 'make assets' as root, (no matter we just login with
> root, or switch to root via su or machinectl shell), 'make assets'
> always fails with a different error.
> 
>     libguestfs: error: could not create appliance through libvirt.
> Original error from libvirt: Cannot access storage file
> '/home/pat/tmp/t5-passt/test/prepared-debian-10-nocloud-amd64.qcow2'
> (as uid:107, gid:107): Permission denied [code=38 int1=13]

Ah, look, UID 107 is usually QEMU on Fedora / RHEL, so libguestfs is
switching to that.

But it shouldn't, because then it won't be able to access the images
you downloaded as root.

Rich, do you know why it happens?

> The XDG_RUNTIME_DIR is no longer an issue, since root can access every
> directory under /run/user. I guess the problem here is that we just
> can't run 'virsh edit' as root.

Wait, it's not 'virsh edit', it's 'virt-edit', and it's not true that
you can't run it as root.

We had explicit reports from libguestfs (virt-edit is part of it, and it
now uses passt to provide networking to the temporary VMs it uses to
edit guest images) being run as root, and passt breaking that in the
past.

We need to support that because virtual machine images might be owned
by root if the virtual machines they belong to can't run unprivileged.

Breaking operation as root is actually pretty bad for security in that
case, since it encourages / forces users to make those images
accessible to other users.

See:

  https://issues.redhat.com/browse/RHEL-36045

  45b8632dcc0e ("conf: Don't lecture user about starting us as root")

  c9b241346569 ("conf, passt, tap: Open socket and PID files before switching UID/GID").

> > > Maybe we can just put it like:
> > >
> > >     Running the commands as root is just not allowed.  If you login
> > > the system with root, don't use su to switch users due to [Bug
> > > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > > and log back in as the intended user, or use 'machinectl shell
> > > --uid=$user'.
> > >
> > > What do you think?  
> >
> > Well, it's free software, so "not allowed" doesn't really mean much.
> >
> > I would simply warn users that it's a bad idea and it's not needed,
> > something like my previous proposal:
> >
> >   * Don't run the tests as root, it's not needed!
> >   * If you really need to, note that ...
> >
> > and then just list the workaround that actually works.
> >
> > I think the most typical need for running things as root is that you
> > don't actually have other users (it happens with some VM images or
> > in embedded systems), so 'machinectl shell --uid=$user' won't really
> > help there.  
> 
> Well, I have to admit that I usually do everything with root on my
> test machines. And I don't see a solution/workaround to fix the issue
> when running 'make assets' as root as c).

It's not so important for our tests, but it would be good to know why
it breaks, in general.

> The workaround proposed is
> just for those who login with root and switch to a non-root user to
> run the tests.
> 
> >
> > Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropriate
> > (does /tmp work?)?
> >  
> > > > > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > > > > +  temporarily disable it by running:
> > > > > > > +
> > > > > > > +        setenforce 0  
> > > > > >
> > > > > > By the way, other than the DHCP client not working on Fedora in a
> > > > > > namespace (which we should really fix, I can look into it if you share
> > > > > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > > > > any other issue with it?
> > > > > >  
> > > > >
> > > > > Sure, I will send you a link containing the audit.log.
> > > > > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > > > > :address'. Looks like an endless loop there. So except the very first
> > > > > few tests, other tests haven't been executed.
> > > > >
> > > > > === pasta/dhcp  
> > > > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>  
> > > > > Interface name
> > > > > DEBUG:DEBUG:? [ -n "eno8303" ]
> > > > > DEBUG:DEBUG:...passed.
> > > > >  
> > > > > > DHCP: address  
> > > > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > > > > DEBUG:DEBUG:...failed.
> > > > >  
> > > > > > DHCP: route  
> > > > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > > > > DEBUG:DEBUG:...failed.
> > > > >  
> > > > > > DHCP: MTU  
> > > > > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > > > > DEBUG:DEBUG:...failed.
> > > > >  
> > > > > > DHCPv6: address  
> > > > > DEBUG:  
> > > >
> > > > Thanks, so it's the issue David recently mentioned with
> > > > dhclient-script(8) being prevented by SELinux from setting up addresses
> > > > and routes via ip(8), even though it's in a detached namespace and that
> > > > should be allowed.
> > > >
> > > > We should probably add something like we do in contrib/selinux/pasta.te
> > > > to https://github.com/fedora-selinux/selinux-policy:
> > > >
> > > >   roleattribute user_r usernetctl_roles;
> > > >   role usernetctl_roles types <whatever dhclient runs as>;
> > > >
> > > > Now, we can disable SELinux temporarily to run tests, but eventually
> > > > we'll want to have tests with DHCP clients in unprivileged setups also
> > > > as part of Fedora automated tests, and I'm fairly sure that those run
> > > > with SELinux in enforcing mode. So we should really fix this.  
> > >
> > > Sure, I will file a ticket for that.  
> >
> > Thanks. Note that it's not a ticket for passt, it's maybe a ticket for
> > fedora-selinux, but I'm not sure if it's really helpful to file issues
> > there. I guess we should try things out and send a merge request.  
>
> Agree. Let's just disable it temporarily to bypass the issue.

Actually, that's not what I meant: I really think we should fix that.
I'm just saying that filing tickets there is usually not very helpful.

Anyway, noted on my list, let me take care of it, the change itself is
kind of trivial. Whether it will be considered / accepted is another
story, but I can try at least.

> > > > By the way, it would also be interesting to see if, once the test suite
> > > > gets past this point, you get further messages in audit.log.
> > > >
> > > > If you do 'setenforce 0', SELinux switches to the so-called "complain
> > > > mode", and warnings are still logged, but they won't block anything.
> > > >
> > > > So, with 'setenforce 0', we can find out from audit.log if we would hit
> > > > further failures.  
> > >
> > > Here is the audit.log:
> > >
> > > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb
> > >
> > > From what I can see, there is no 'avc:  denied' after the dhcp cases.  
> >
> > [looking at log you attached later] great, I don't see other issues
> > either! So it seems to be just that, and then we'll be able to run
> > tests on Fedora-like distributions with SELinux enabled.

-- 
Stefano

Re: [PATCH] test: Update README.md

[Richard W.M. Jones]

On Wed, Sep 24, 2025 at 10:46:32AM +0200, Stefano Brivio wrote:
> [Cc'ing Rich... Rich, see my first question below]
> 
> On Wed, 24 Sep 2025 09:58:57 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
> 
> > On Tue, Sep 23, 2025 at 6:32 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > >
> > > On Tue, 23 Sep 2025 14:36:41 +0800
> > > Yumei Huang <yuhuang@redhat.com> wrote:
> > >  
> > > > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > > >
> > > > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > >  
> > > > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > > > > >
> > > > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > > > >  
> > > > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > > > ---
> > > > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > > > index 91ca603..e3e9d37 100644
> > > > > > > > --- a/test/README.md
> > > > > > > > +++ b/test/README.md
> > > > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > > > >
> > > > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > > > >
> > > > > > > >  ## Regular test
> > > > > > > >
> > > > > > > > -Just issue:
> > > > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > > > +
> > > > > > > > +    cd test
> > > > > > > > +    make assets
> > > > > > > > +
> > > > > > > > +Then issue:
> > > > > > > >
> > > > > > > >      ./run
> > > > > > > >
> > > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > > > >
> > > > > > > >      PCAP=1 TRACE=1 ./run
> > > > > > > >
> > > > > > > > +**Note:**
> > > > > > > > +
> > > > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.  
> > > > > > >
> > > > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > > > quite some time figuring that out (for other reasons):
> > > > > > >
> > > > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > > > >
> > > > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > > > with 'machinectl shell' instead.
> > > > > > >
> > > > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > > > >
> > > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > > > make the wording stronger, something like:
> > > > > > >
> > > > > > > * Don't run the tests as root, it's not needed!
> > > > > > > * If you really need to, note that ...
> > > > > > >  
> > > > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > > > +  correct runtime directory is set up.  
> > > > > > >
> > > > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > > > whatever reason.  
> > > > > >
> > > > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > > > running 'make assets',
> > > > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.  
> > > > >
> > > > > Ah, I didn't know! So this is actually similar to
> > > > > https://issues.redhat.com/browse/RHEL-70222.
> > > > >  
> > > > > > If we run 'make assets' with root, the error is like this:
> > > > > >
> > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > > libguestfs: error: could not create appliance through libvirt.
> > > > > > Original error from libvirt: Cannot access storage file
> > > > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > > > >
> > > > > > If we switch to a non-root user via 'su', the error is like this:
> > > > > >
> > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > > > '/run/user/0/libvirt': Permission denied
> > > > > > libguestfs: error: could not connect to libvirt (URI =
> > > > > > qemu:///session): Cannot create user runtime directory
> > > > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > > > >
> > > > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > > > exact cmd here? I tried this, seems not work.
> > > > > >
> > > > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > > > /home/test/passt/test/make assets
> > > > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > > > >
> > > > > >     Connection to the local host terminated.  
> > > > >
> > > > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > > > replacement), that is:
> > > > >
> > > > >     $ machinectl shell
> > > > >     # make assets
> > > > >
> > > > > ...because that one will set XDG_RUNTIME_DIR.  
> > > >
> > > > Yes, 'machinectl shell' will solve the issue when switching to a
> > > > non-root user via su. But it doesn't solve the issue when running
> > > > 'make assets' as root. They are actually different issues as above.  
> > >
> > > Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> > > Does that work?  
> > 
> > I guess I need to clarify the issues more clearly.
> > 
> > a) If we login the system with the non-root user, `/run/user/ID` is
> > created and XDG_RUNTIME_DIR is pointing to that correctly. So 'make
> > assets' works well.
> > 
> > b) If we login the system with root, then switch to a non-root user
> > via 'su', 'make assets' fails due to Bug 967509. XDG_RUNTIME_DIR is
> > not reset and points to /run/user/(ID of the previous user), which is
> > /run/user/0.
> > 
> >     libguestfs: error: could not connect to libvirt (URI =
> > qemu:///session): Cannot create user runtime directory
> > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > 
> > Switching the user with 'machinectl shell --uid=$user' can solve the issue.
> > 
> > c) If we run 'make assets' as root, (no matter we just login with
> > root, or switch to root via su or machinectl shell), 'make assets'
> > always fails with a different error.
> > 
> >     libguestfs: error: could not create appliance through libvirt.
> > Original error from libvirt: Cannot access storage file
> > '/home/pat/tmp/t5-passt/test/prepared-debian-10-nocloud-amd64.qcow2'
> > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> 
> Ah, look, UID 107 is usually QEMU on Fedora / RHEL, so libguestfs is
> switching to that.
> 
> But it shouldn't, because then it won't be able to access the images
> you downloaded as root.
> 
> Rich, do you know why it happens?

Libvirt is doing the user switching, and yes it's annoying.  See this
bug that's so old it's about to start high school:

  https://bugzilla.redhat.com/show_bug.cgi?id=1045069

Having said that, it might also be a good idea not to run stuff as
root.  Neither libvirt nor libguestfs need it.

> > The XDG_RUNTIME_DIR is no longer an issue, since root can access every
> > directory under /run/user. I guess the problem here is that we just
> > can't run 'virsh edit' as root.
> 
> Wait, it's not 'virsh edit', it's 'virt-edit', and it's not true that
> you can't run it as root.
> 
> We had explicit reports from libguestfs (virt-edit is part of it, and it
> now uses passt to provide networking to the temporary VMs it uses to
> edit guest images) being run as root, and passt breaking that in the
> past.
> 
> We need to support that because virtual machine images might be owned
> by root if the virtual machines they belong to can't run unprivileged.
> 
> Breaking operation as root is actually pretty bad for security in that
> case, since it encourages / forces users to make those images
> accessible to other users.
> 
> See:
> 
>   https://issues.redhat.com/browse/RHEL-36045
> 
>   45b8632dcc0e ("conf: Don't lecture user about starting us as root")
> 
>   c9b241346569 ("conf, passt, tap: Open socket and PID files before switching UID/GID").
> 
> > > > Maybe we can just put it like:
> > > >
> > > >     Running the commands as root is just not allowed.  If you login
> > > > the system with root, don't use su to switch users due to [Bug
> > > > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > > > and log back in as the intended user, or use 'machinectl shell
> > > > --uid=$user'.
> > > >
> > > > What do you think?  
> > >
> > > Well, it's free software, so "not allowed" doesn't really mean much.
> > >
> > > I would simply warn users that it's a bad idea and it's not needed,
> > > something like my previous proposal:
> > >
> > >   * Don't run the tests as root, it's not needed!
> > >   * If you really need to, note that ...
> > >
> > > and then just list the workaround that actually works.
> > >
> > > I think the most typical need for running things as root is that you
> > > don't actually have other users (it happens with some VM images or
> > > in embedded systems), so 'machinectl shell --uid=$user' won't really
> > > help there.  
> > 
> > Well, I have to admit that I usually do everything with root on my
> > test machines. And I don't see a solution/workaround to fix the issue
> > when running 'make assets' as root as c).
> 
> It's not so important for our tests, but it would be good to know why
> it breaks, in general.
> 
> > The workaround proposed is
> > just for those who login with root and switch to a non-root user to
> > run the tests.
> > 
> > >
> > > Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropriate
> > > (does /tmp work?)?
> > >  
> > > > > > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > > > > > +  temporarily disable it by running:
> > > > > > > > +
> > > > > > > > +        setenforce 0  
> > > > > > >
> > > > > > > By the way, other than the DHCP client not working on Fedora in a
> > > > > > > namespace (which we should really fix, I can look into it if you share
> > > > > > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > > > > > any other issue with it?
> > > > > > >  
> > > > > >
> > > > > > Sure, I will send you a link containing the audit.log.
> > > > > > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > > > > > :address'. Looks like an endless loop there. So except the very first
> > > > > > few tests, other tests haven't been executed.
> > > > > >
> > > > > > === pasta/dhcp  
> > > > > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>  
> > > > > > Interface name
> > > > > > DEBUG:DEBUG:? [ -n "eno8303" ]
> > > > > > DEBUG:DEBUG:...passed.
> > > > > >  
> > > > > > > DHCP: address  
> > > > > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > > > > > DEBUG:DEBUG:...failed.
> > > > > >  
> > > > > > > DHCP: route  
> > > > > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > > > > > DEBUG:DEBUG:...failed.
> > > > > >  
> > > > > > > DHCP: MTU  
> > > > > > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > > > > > DEBUG:DEBUG:...failed.
> > > > > >  
> > > > > > > DHCPv6: address  
> > > > > > DEBUG:  
> > > > >
> > > > > Thanks, so it's the issue David recently mentioned with
> > > > > dhclient-script(8) being prevented by SELinux from setting up addresses
> > > > > and routes via ip(8), even though it's in a detached namespace and that
> > > > > should be allowed.
> > > > >
> > > > > We should probably add something like we do in contrib/selinux/pasta.te
> > > > > to https://github.com/fedora-selinux/selinux-policy:
> > > > >
> > > > >   roleattribute user_r usernetctl_roles;
> > > > >   role usernetctl_roles types <whatever dhclient runs as>;
> > > > >
> > > > > Now, we can disable SELinux temporarily to run tests, but eventually
> > > > > we'll want to have tests with DHCP clients in unprivileged setups also
> > > > > as part of Fedora automated tests, and I'm fairly sure that those run
> > > > > with SELinux in enforcing mode. So we should really fix this.  
> > > >
> > > > Sure, I will file a ticket for that.  
> > >
> > > Thanks. Note that it's not a ticket for passt, it's maybe a ticket for
> > > fedora-selinux, but I'm not sure if it's really helpful to file issues
> > > there. I guess we should try things out and send a merge request.  
> >
> > Agree. Let's just disable it temporarily to bypass the issue.
> 
> Actually, that's not what I meant: I really think we should fix that.
> I'm just saying that filing tickets there is usually not very helpful.
> 
> Anyway, noted on my list, let me take care of it, the change itself is
> kind of trivial. Whether it will be considered / accepted is another
> story, but I can try at least.
> 
> > > > > By the way, it would also be interesting to see if, once the test suite
> > > > > gets past this point, you get further messages in audit.log.
> > > > >
> > > > > If you do 'setenforce 0', SELinux switches to the so-called "complain
> > > > > mode", and warnings are still logged, but they won't block anything.
> > > > >
> > > > > So, with 'setenforce 0', we can find out from audit.log if we would hit
> > > > > further failures.  
> > > >
> > > > Here is the audit.log:
> > > >
> > > > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb
> > > >
> > > > From what I can see, there is no 'avc:  denied' after the dhcp cases.  
> > >
> > > [looking at log you attached later] great, I don't see other issues
> > > either! So it seems to be just that, and then we'll be able to run
> > > tests on Fedora-like distributions with SELinux enabled.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

Re: [PATCH] test: Update README.md

[Stefano Brivio]

On Wed, 24 Sep 2025 09:56:21 +0100
"Richard W.M. Jones" <rjones@redhat.com> wrote:

> On Wed, Sep 24, 2025 at 10:46:32AM +0200, Stefano Brivio wrote:
> > [Cc'ing Rich... Rich, see my first question below]
> > 
> > On Wed, 24 Sep 2025 09:58:57 +0800
> > Yumei Huang <yuhuang@redhat.com> wrote:
> >   
> > > On Tue, Sep 23, 2025 at 6:32 PM Stefano Brivio <sbrivio@redhat.com> wrote:  
> > > >
> > > > On Tue, 23 Sep 2025 14:36:41 +0800
> > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > >    
> > > > > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio <sbrivio@redhat.com> wrote:    
> > > > > >
> > > > > > On Mon, 22 Sep 2025 11:03:23 +0800
> > > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > > >    
> > > > > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio <sbrivio@redhat.com> wrote:    
> > > > > > > >
> > > > > > > > On Fri, 19 Sep 2025 09:43:29 +0800
> > > > > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > > > > >    
> > > > > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> > > > > > > > > ---
> > > > > > > > >  test/README.md | 31 +++++++++++++++++++++++++++++--
> > > > > > > > >  1 file changed, 29 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/test/README.md b/test/README.md
> > > > > > > > > index 91ca603..e3e9d37 100644
> > > > > > > > > --- a/test/README.md
> > > > > > > > > +++ b/test/README.md
> > > > > > > > > @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions:
> > > > > > > > >      git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower
> > > > > > > > >      lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64
> > > > > > > > >      qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86
> > > > > > > > > -    qemu-system-x86 sipcalc socat strace tmux uidmap valgrind
> > > > > > > > > +    sipcalc socat strace tmux uidmap valgrind
> > > > > > > > >
> > > > > > > > >  NOTE: the tests need a qemu version >= 7.2, or one that contains commit
> > > > > > > > >  13c6be96618c ("net: stream: add unix socket"): this change introduces support
> > > > > > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly needed:
> > > > > > > > >
> > > > > > > > >  ## Regular test
> > > > > > > > >
> > > > > > > > > -Just issue:
> > > > > > > > > +Before running the tests, you need to prepare the required assets:
> > > > > > > > > +
> > > > > > > > > +    cd test
> > > > > > > > > +    make assets
> > > > > > > > > +
> > > > > > > > > +Then issue:
> > > > > > > > >
> > > > > > > > >      ./run
> > > > > > > > >
> > > > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
> > > > > > > > >
> > > > > > > > >      PCAP=1 TRACE=1 ./run
> > > > > > > > >
> > > > > > > > > +**Note:**
> > > > > > > > > +
> > > > > > > > > +* It's recommended to run the commands as a non-root user.
> > > > > > > > > +  Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509),
> > > > > > > > > +  if you switch users with `su` or `sudo`, the directory `/run/user/ID` may
> > > > > > > > > +  not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to
> > > > > > > > > +  `/run/user/0` instead of `/run/user/ID`, which can cause error.    
> > > > > > > >
> > > > > > > > Thanks for the research, I wasn't aware of that, and recently spent
> > > > > > > > quite some time figuring that out (for other reasons):
> > > > > > > >
> > > > > > > >   https://issues.redhat.com/browse/RHEL-70222
> > > > > > > >
> > > > > > > > in that case, XDG_RUNTIME_DIR was simply not set. Things were working
> > > > > > > > with 'machinectl shell' instead.
> > > > > > > >
> > > > > > > > At the same time: running this whole stuff as root sounds rather crazy,
> > > > > > > > unless it's a throw-away VMs with absolutely nothing important on it.
> > > > > > > >
> > > > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would maybe
> > > > > > > > make the wording stronger, something like:
> > > > > > > >
> > > > > > > > * Don't run the tests as root, it's not needed!
> > > > > > > > * If you really need to, note that ...
> > > > > > > >    
> > > > > > > > > +  **Workaround:** Log out and log back in as the intended user to ensure the
> > > > > > > > > +  correct runtime directory is set up.    
> > > > > > > >
> > > > > > > > We could also suggest 'machinectl shell' if it's really needed for
> > > > > > > > whatever reason.    
> > > > > > >
> > > > > > > I'm not sure how 'machinectl shell' works here. The error happens when
> > > > > > > running 'make assets',
> > > > > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.    
> > > > > >
> > > > > > Ah, I didn't know! So this is actually similar to
> > > > > > https://issues.redhat.com/browse/RHEL-70222.
> > > > > >    
> > > > > > > If we run 'make assets' with root, the error is like this:
> > > > > > >
> > > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > > > libguestfs: error: could not create appliance through libvirt.
> > > > > > > Original error from libvirt: Cannot access storage file
> > > > > > > '/home/test/passt/test/prepared-debian-8.11.0-openstack-amd64.qcow2'
> > > > > > > (as uid:107, gid:107): Permission denied [code=38 int1=13]
> > > > > > >
> > > > > > > If we switch to a non-root user via 'su', the error is like this:
> > > > > > >
> > > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd64.qcow2
> > > > > > > libvirt: XML-RPC error : Cannot create user runtime directory
> > > > > > > '/run/user/0/libvirt': Permission denied
> > > > > > > libguestfs: error: could not connect to libvirt (URI =
> > > > > > > qemu:///session): Cannot create user runtime directory
> > > > > > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > > > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qcow2] Error 1
> > > > > > >
> > > > > > > Do you mean to run 'make assets' with 'machinectl shell'? What's the
> > > > > > > exact cmd here? I tried this, seems not work.
> > > > > > >
> > > > > > >     # machinectl shell --uid=$(id -u pat) .host
> > > > > > > /home/test/passt/test/make assets
> > > > > > >     Connected to the local host. Press ^] three times within 1s to exit session.
> > > > > > >
> > > > > > >     Connection to the local host terminated.    
> > > > > >
> > > > > > No, I mean using 'machinectl shell' instead of 'su' (it's intended as a
> > > > > > replacement), that is:
> > > > > >
> > > > > >     $ machinectl shell
> > > > > >     # make assets
> > > > > >
> > > > > > ...because that one will set XDG_RUNTIME_DIR.    
> > > > >
> > > > > Yes, 'machinectl shell' will solve the issue when switching to a
> > > > > non-root user via su. But it doesn't solve the issue when running
> > > > > 'make assets' as root. They are actually different issues as above.    
> > > >
> > > > Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe?
> > > > Does that work?    
> > > 
> > > I guess I need to clarify the issues more clearly.
> > > 
> > > a) If we login the system with the non-root user, `/run/user/ID` is
> > > created and XDG_RUNTIME_DIR is pointing to that correctly. So 'make
> > > assets' works well.
> > > 
> > > b) If we login the system with root, then switch to a non-root user
> > > via 'su', 'make assets' fails due to Bug 967509. XDG_RUNTIME_DIR is
> > > not reset and points to /run/user/(ID of the previous user), which is
> > > /run/user/0.
> > > 
> > >     libguestfs: error: could not connect to libvirt (URI =
> > > qemu:///session): Cannot create user runtime directory
> > > '/run/user/0/libvirt': Permission denied [code=38 int1=13]
> > > 
> > > Switching the user with 'machinectl shell --uid=$user' can solve the issue.
> > > 
> > > c) If we run 'make assets' as root, (no matter we just login with
> > > root, or switch to root via su or machinectl shell), 'make assets'
> > > always fails with a different error.
> > > 
> > >     libguestfs: error: could not create appliance through libvirt.
> > > Original error from libvirt: Cannot access storage file
> > > '/home/pat/tmp/t5-passt/test/prepared-debian-10-nocloud-amd64.qcow2'
> > > (as uid:107, gid:107): Permission denied [code=38 int1=13]  
> > 
> > Ah, look, UID 107 is usually QEMU on Fedora / RHEL, so libguestfs is
> > switching to that.
> > 
> > But it shouldn't, because then it won't be able to access the images
> > you downloaded as root.
> > 
> > Rich, do you know why it happens?  
> 
> Libvirt is doing the user switching, and yes it's annoying.  See this
> bug that's so old it's about to start high school:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1045069

Ouch. Thanks. It looks like it wasn't admitted to high school though.

And now that you say that, I just realised that it would be as simple
as:

  https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root

  LIBGUESTFS_BACKEND=direct virt-edit...

Yumei, David, perhaps we could just change test/prepare-distro-img.sh
to that?

It won't hurt when running things as non-root, either.

> Having said that, it might also be a good idea not to run stuff as
> root.  Neither libvirt nor libguestfs need it.

Sure, and that's what passt is all about. There might be somewhat
legitimate use cases, though, such as throw-away VMs, or embedded
systems where you don't have other users at all.

One can create them (assuming CONFIG_MULTIUSER is enabled in the
kernel) but if we can make things slightly more convenient with low
effort, I would.

> > > The XDG_RUNTIME_DIR is no longer an issue, since root can access every
> > > directory under /run/user. I guess the problem here is that we just
> > > can't run 'virsh edit' as root.  
> > 
> > Wait, it's not 'virsh edit', it's 'virt-edit', and it's not true that
> > you can't run it as root.
> > 
> > We had explicit reports from libguestfs (virt-edit is part of it, and it
> > now uses passt to provide networking to the temporary VMs it uses to
> > edit guest images) being run as root, and passt breaking that in the
> > past.
> > 
> > We need to support that because virtual machine images might be owned
> > by root if the virtual machines they belong to can't run unprivileged.
> > 
> > Breaking operation as root is actually pretty bad for security in that
> > case, since it encourages / forces users to make those images
> > accessible to other users.
> > 
> > See:
> > 
> >   https://issues.redhat.com/browse/RHEL-36045
> > 
> >   45b8632dcc0e ("conf: Don't lecture user about starting us as root")
> > 
> >   c9b241346569 ("conf, passt, tap: Open socket and PID files before switching UID/GID").
> >   
> > > > > Maybe we can just put it like:
> > > > >
> > > > >     Running the commands as root is just not allowed.  If you login
> > > > > the system with root, don't use su to switch users due to [Bug
> > > > > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509). Log out
> > > > > and log back in as the intended user, or use 'machinectl shell
> > > > > --uid=$user'.
> > > > >
> > > > > What do you think?    
> > > >
> > > > Well, it's free software, so "not allowed" doesn't really mean much.
> > > >
> > > > I would simply warn users that it's a bad idea and it's not needed,
> > > > something like my previous proposal:
> > > >
> > > >   * Don't run the tests as root, it's not needed!
> > > >   * If you really need to, note that ...
> > > >
> > > > and then just list the workaround that actually works.
> > > >
> > > > I think the most typical need for running things as root is that you
> > > > don't actually have other users (it happens with some VM images or
> > > > in embedded systems), so 'machinectl shell --uid=$user' won't really
> > > > help there.    
> > > 
> > > Well, I have to admit that I usually do everything with root on my
> > > test machines. And I don't see a solution/workaround to fix the issue
> > > when running 'make assets' as root as c).  
> > 
> > It's not so important for our tests, but it would be good to know why
> > it breaks, in general.
> >   
> > > The workaround proposed is
> > > just for those who login with root and switch to a non-root user to
> > > run the tests.
> > >   
> > > >
> > > > Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropriate
> > > > (does /tmp work?)?
> > > >    
> > > > > > > > > +* SELinux may prevent the tests from running correctly. To avoid this,
> > > > > > > > > +  temporarily disable it by running:
> > > > > > > > > +
> > > > > > > > > +        setenforce 0    
> > > > > > > >
> > > > > > > > By the way, other than the DHCP client not working on Fedora in a
> > > > > > > > namespace (which we should really fix, I can look into it if you share
> > > > > > > > the messages you're getting from /var/log/audit/audit.log), did you hit
> > > > > > > > any other issue with it?
> > > > > > > >    
> > > > > > >
> > > > > > > Sure, I will send you a link containing the audit.log.
> > > > > > > BTW, if 'setenforce 1', the tests would get stuck at 'DHCPv6
> > > > > > > :address'. Looks like an endless loop there. So except the very first
> > > > > > > few tests, other tests haven't been executed.
> > > > > > >
> > > > > > > === pasta/dhcp    
> > > > > > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:>    
> > > > > > > Interface name
> > > > > > > DEBUG:DEBUG:? [ -n "eno8303" ]
> > > > > > > DEBUG:DEBUG:...passed.
> > > > > > >    
> > > > > > > > DHCP: address    
> > > > > > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.136.30 ] < failed.
> > > > > > > DEBUG:DEBUG:...failed.
> > > > > > >    
> > > > > > > > DHCP: route    
> > > > > > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ = 10.72.139.254 ] < failed.
> > > > > > > DEBUG:DEBUG:...failed.
> > > > > > >    
> > > > > > > > DHCP: MTU    
> > > > > > > DEBUG:DEBUG:? [ 1500 = 65520 ] < failed.
> > > > > > > DEBUG:DEBUG:...failed.
> > > > > > >    
> > > > > > > > DHCPv6: address    
> > > > > > > DEBUG:    
> > > > > >
> > > > > > Thanks, so it's the issue David recently mentioned with
> > > > > > dhclient-script(8) being prevented by SELinux from setting up addresses
> > > > > > and routes via ip(8), even though it's in a detached namespace and that
> > > > > > should be allowed.
> > > > > >
> > > > > > We should probably add something like we do in contrib/selinux/pasta.te
> > > > > > to https://github.com/fedora-selinux/selinux-policy:
> > > > > >
> > > > > >   roleattribute user_r usernetctl_roles;
> > > > > >   role usernetctl_roles types <whatever dhclient runs as>;
> > > > > >
> > > > > > Now, we can disable SELinux temporarily to run tests, but eventually
> > > > > > we'll want to have tests with DHCP clients in unprivileged setups also
> > > > > > as part of Fedora automated tests, and I'm fairly sure that those run
> > > > > > with SELinux in enforcing mode. So we should really fix this.    
> > > > >
> > > > > Sure, I will file a ticket for that.    
> > > >
> > > > Thanks. Note that it's not a ticket for passt, it's maybe a ticket for
> > > > fedora-selinux, but I'm not sure if it's really helpful to file issues
> > > > there. I guess we should try things out and send a merge request.    
> > >
> > > Agree. Let's just disable it temporarily to bypass the issue.  
> > 
> > Actually, that's not what I meant: I really think we should fix that.
> > I'm just saying that filing tickets there is usually not very helpful.
> > 
> > Anyway, noted on my list, let me take care of it, the change itself is
> > kind of trivial. Whether it will be considered / accepted is another
> > story, but I can try at least.
> >   
> > > > > > By the way, it would also be interesting to see if, once the test suite
> > > > > > gets past this point, you get further messages in audit.log.
> > > > > >
> > > > > > If you do 'setenforce 0', SELinux switches to the so-called "complain
> > > > > > mode", and warnings are still logged, but they won't block anything.
> > > > > >
> > > > > > So, with 'setenforce 0', we can find out from audit.log if we would hit
> > > > > > further failures.    
> > > > >
> > > > > Here is the audit.log:
> > > > >
> > > > > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb
> > > > >
> > > > > From what I can see, there is no 'avc:  denied' after the dhcp cases.    
> > > >
> > > > [looking at log you attached later] great, I don't see other issues
> > > > either! So it seems to be just that, and then we'll be able to run
> > > > tests on Fedora-like distributions with SELinux enabled.  

-- 
Stefano

Re: [PATCH] test: Update README.md

[Richard W.M. Jones]

On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:
> And now that you say that, I just realised that it would be as simple
> as:
> 
>   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> 
>   LIBGUESTFS_BACKEND=direct virt-edit...

While that will indeed work, we're trying to discourage people from
doing that, since it removes the other good things that libvirt does,
such as setting up SELinux.

The real solution here IMHO is for libvirt to make session mode work
for root without changing UID.  It actually goes out of its way to
stop this working at the moment[1].

Rich.

[1] In qemuStateInitialize -> virQEMUDriverConfigNew, I think

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Re: [PATCH] test: Update README.md

[Daniel P. Berrangé]

On Wed, Sep 24, 2025 at 11:31:31AM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:
> > And now that you say that, I just realised that it would be as simple
> > as:
> > 
> >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > 
> >   LIBGUESTFS_BACKEND=direct virt-edit...
> 
> While that will indeed work, we're trying to discourage people from
> doing that, since it removes the other good things that libvirt does,
> such as setting up SELinux.
> 
> The real solution here IMHO is for libvirt to make session mode work
> for root without changing UID.  It actually goes out of its way to
> stop this working at the moment[1].

We made it possible to run QEMU as root:root while still using
system mode quite a while ago now. It requires adding this
to the XML:

  <seclabel type='static' model='dac' relabel='yes'>
    <label>+0:+0</label>
  </seclabel>

AFAICT, the resulting QEMU will also still have all capabiltiies
set, most importantly CAP_DAC_OVERRIDE.  So unless I'm missing
something there shouldn't be anything that can't be done with
system mode, that a session mode would allow.

I thought I had already suggested that libguestfs use this
seclabel, but don't recall if it was ever tried, or if we
hit some other roadblock.

> [1] In qemuStateInitialize -> virQEMUDriverConfigNew, I think

Well that's where the initial control is, but it isn't a simple as just
removing/changing that code. When running as root, we have access to a
lot of system wide resources, and libvirt needs to track which are in
use by VMs or not. We can't do that tracking if we have two separate
privileged daemons for both system mode and a root-session mode.

It might be possible to have a single daemon service both roles. VMs
defined via a session mode connection would auto-add the above
<seclabel> to default to running as root. It would also need to
dynamically change what's reported in capabilities to reflect this
different default, and more systemd socket unit files at the locations
that the session mode client app looks for.

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

Re: [PATCH] test: Update README.md

[Stefano Brivio]

On Wed, 24 Sep 2025 11:31:31 +0100
"Richard W.M. Jones" <rjones@redhat.com> wrote:

> On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:
> > And now that you say that, I just realised that it would be as simple
> > as:
> > 
> >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > 
> >   LIBGUESTFS_BACKEND=direct virt-edit...  
> 
> While that will indeed work, we're trying to discourage people from
> doing that, since it removes the other good things that libvirt does,
> such as setting up SELinux.

Oh, I see. I guess it makes sense, with a number of caveats:

1. libvirt's SELinux policy doesn't seem to be really maintainable /
   long-term sustainable to me, especially because it's still part of
   fedora-selinux

2. it adds a rather artificial dependency on libvirt, so in the end
   you're running more things, and more complicated ones, even if it's
   not needed

3. the profile is still much looser than what a libguestfs specific
   profile could be, see for example the AppArmor policy I introduced
   at:

     https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a6621d0b61907f9269a2506680684f

   which, despite being rather loose, is still arguably much stricter
   than this beast (and related add-ons):

     https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.sbin.libvirtd.in

   and I think a strict subset of it, as well.

   Now, it's all a bit simpler with AppArmor as we don't have the
   multi-category security stuff, but conceptually this point should
   apply to SELinux too.

Still, to prepare guest images in our test suite, I think we could
happily use that trick.

For this specific usage, we're not particularly concerned about
security, and guests are essentially trusted. We're using virt-edit to
add root auto-login without password, that's how much we care about
security there.

> The real solution here IMHO is for libvirt to make session mode work
> for root without changing UID.  It actually goes out of its way to
> stop this working at the moment[1].
> 
> Rich.
> 
> [1] In qemuStateInitialize -> virQEMUDriverConfigNew, I think

Another bit of the solution is probably to introduce a separate
SELinux policy for libguestfs itself. No, sorry, I can't volunteer for
that right now. :(

-- 
Stefano

Re: [PATCH] test: Update README.md

[Daniel P. Berrangé]

On Wed, Sep 24, 2025 at 01:05:53PM +0200, Stefano Brivio wrote:
> On Wed, 24 Sep 2025 11:31:31 +0100
> "Richard W.M. Jones" <rjones@redhat.com> wrote:
> 
> > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:
> > > And now that you say that, I just realised that it would be as simple
> > > as:
> > > 
> > >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > > 
> > >   LIBGUESTFS_BACKEND=direct virt-edit...  
> > 
> > While that will indeed work, we're trying to discourage people from
> > doing that, since it removes the other good things that libvirt does,
> > such as setting up SELinux.
> 
> Oh, I see. I guess it makes sense, with a number of caveats:
> 
> 1. libvirt's SELinux policy doesn't seem to be really maintainable /
>    long-term sustainable to me, especially because it's still part of
>    fedora-selinux

Well it isn't ideal that Fedora policy is largely centralized, but
it has been maintained it since 2007, so claiming it is not long
term sustainable is just FUD.

> 2. it adds a rather artificial dependency on libvirt, so in the end
>    you're running more things, and more complicated ones, even if it's
>    not needed

Libvirt provides a stable interface to interacting with QEMU
over decades. QEMU's own interface is only guaranteed stable
over 2 releases.  As QEMU changes its interface and/or best
practice configuration approach, libvirt adapts to this so
every app doesn't have to repeat this work.

> 3. the profile is still much looser than what a libguestfs specific
>    profile could be, see for example the AppArmor policy I introduced
>    at:
> 
>      https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a6621d0b61907f9269a2506680684f
> 
>    which, despite being rather loose, is still arguably much stricter
>    than this beast (and related add-ons):
> 
>      https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.sbin.libvirtd.in
> 
>    and I think a strict subset of it, as well.

This is the policy for the libvirt daemon, which is separate from the
policy that the QEMU guest runs under - the latter is constrained to
limit access to resources configured for the guest VM.

The libvirt daemon policy needs to be loose by default, since users
want libvirt to be able to access a wide range of files and resources.
This same need applies to guestfish - it needs to access arbitrarily
specified disk images, so would need a very loose policy. Only the
spawned QEMU could be confined strictly, and that would be equiv to
what is already done with libvirt's policy for QEMU.


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

Re: [PATCH] test: Update README.md

[Stefano Brivio]

On Wed, 24 Sep 2025 12:20:03 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Wed, Sep 24, 2025 at 01:05:53PM +0200, Stefano Brivio wrote:
> > On Wed, 24 Sep 2025 11:31:31 +0100
> > "Richard W.M. Jones" <rjones@redhat.com> wrote:
> >   
> > > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:  
> > > > And now that you say that, I just realised that it would be as simple
> > > > as:
> > > > 
> > > >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > > > 
> > > >   LIBGUESTFS_BACKEND=direct virt-edit...    
> > > 
> > > While that will indeed work, we're trying to discourage people from
> > > doing that, since it removes the other good things that libvirt does,
> > > such as setting up SELinux.  
> > 
> > Oh, I see. I guess it makes sense, with a number of caveats:
> > 
> > 1. libvirt's SELinux policy doesn't seem to be really maintainable /
> >    long-term sustainable to me, especially because it's still part of
> >    fedora-selinux  
> 
> Well it isn't ideal that Fedora policy is largely centralized, but
> it has been maintained it since 2007, so claiming it is not long
> term sustainable is just FUD.

I'd rather call it observation. We're just piling up workarounds
because merge requests are not really evaluated or accepted, for
example https://github.com/fedora-selinux/selinux-policy/pull/1613.
Your own comment to it:

  https://github.com/fedora-selinux/selinux-policy/pull/1613#issuecomment-1467759276

perfectly explains one of the biggest maintainability concerns I
have, because not being able to use interfaces as designed leads to
issues such as:

  https://github.com/fedora-selinux/selinux-policy/issues/2579

for which, again, I could propose a simple change, but I don't
exactly have confidence that it will be considered. That leads in turn
to more workarounds, say:

  https://passt.top/passt/commit/?id=87471731e6bb0b5df3a50277527caf3381b45ee4
  https://passt.top/passt/commit/?id=98d474c8950e9cc5715d5686614fb0f504377303

I don't understand how the fact that it's been like that since 2007
would suggest a positive or negative correlation to maintainability.

Things keeps breaking and I keep adding more workarounds, not fixes.
You can go ahead and blame me for that, but I was talking about how *I*
perceive maintainability. Again:

> 1. libvirt's SELinux policy doesn't seem to be really maintainable /
>    long-term sustainable to me
                              ^^

...we probably have different concepts of it. That doesn't make it FUD.

> > 2. it adds a rather artificial dependency on libvirt, so in the end
> >    you're running more things, and more complicated ones, even if it's
> >    not needed  
> 
> Libvirt provides a stable interface to interacting with QEMU
> over decades. QEMU's own interface is only guaranteed stable
> over 2 releases.  As QEMU changes its interface and/or best
> practice configuration approach, libvirt adapts to this so
> every app doesn't have to repeat this work.

It depends on the use case. For the use case at hand, we would be
absolutely fine with things breaking every six months, or even more
frequently.

> > 3. the profile is still much looser than what a libguestfs specific
> >    profile could be, see for example the AppArmor policy I introduced
> >    at:
> > 
> >      https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a6621d0b61907f9269a2506680684f
> > 
> >    which, despite being rather loose, is still arguably much stricter
> >    than this beast (and related add-ons):
> > 
> >      https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.sbin.libvirtd.in
> > 
> >    and I think a strict subset of it, as well.  
> 
> This is the policy for the libvirt daemon, which is separate from the
> policy that the QEMU guest runs under - the latter is constrained to
> limit access to resources configured for the guest VM.
> 
> The libvirt daemon policy needs to be loose by default, since users
> want libvirt to be able to access a wide range of files and resources.
> This same need applies to guestfish - it needs to access arbitrarily
> specified disk images, so would need a very loose policy.

About disk images, of course, that's what I added for libguestfs:

  /** mrwlk

and that's the same in libvirt's AppArmor policy.

The set of permitted capabilities is very different, though, and
libguestfs doesn't of course need all those helpers or, say, the
ability to mount /dev, which, with AppArmor, can't be qualified /
limited much further than that.

> Only the
> spawned QEMU could be confined strictly, and that would be equiv to
> what is already done with libvirt's policy for QEMU.

...see links above? Those are not equivalent.

-- 
Stefano

Re: [PATCH] test: Update README.md

[Yumei Huang]

On Wed, Sep 24, 2025 at 7:06 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Wed, 24 Sep 2025 11:31:31 +0100
> "Richard W.M. Jones" <rjones@redhat.com> wrote:
>
> > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:
> > > And now that you say that, I just realised that it would be as simple
> > > as:
> > >
> > >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > >
> > >   LIBGUESTFS_BACKEND=direct virt-edit...
> >
> > While that will indeed work, we're trying to discourage people from
> > doing that, since it removes the other good things that libvirt does,
> > such as setting up SELinux.
>
> Oh, I see. I guess it makes sense, with a number of caveats:
>
> 1. libvirt's SELinux policy doesn't seem to be really maintainable /
>    long-term sustainable to me, especially because it's still part of
>    fedora-selinux
>
> 2. it adds a rather artificial dependency on libvirt, so in the end
>    you're running more things, and more complicated ones, even if it's
>    not needed
>
> 3. the profile is still much looser than what a libguestfs specific
>    profile could be, see for example the AppArmor policy I introduced
>    at:
>
>      https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a6621d0b61907f9269a2506680684f
>
>    which, despite being rather loose, is still arguably much stricter
>    than this beast (and related add-ons):
>
>      https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.sbin.libvirtd.in
>
>    and I think a strict subset of it, as well.
>
>    Now, it's all a bit simpler with AppArmor as we don't have the
>    multi-category security stuff, but conceptually this point should
>    apply to SELinux too.
>
> Still, to prepare guest images in our test suite, I think we could
> happily use that trick.
>
> For this specific usage, we're not particularly concerned about
> security, and guests are essentially trusted. We're using virt-edit to
> add root auto-login without password, that's how much we care about
> security there.

Seems nobody is objecting to this. I will send another patch to add the trick.

>
> > The real solution here IMHO is for libvirt to make session mode work
> > for root without changing UID.  It actually goes out of its way to
> > stop this working at the moment[1].
> >
> > Rich.
> >
> > [1] In qemuStateInitialize -> virQEMUDriverConfigNew, I think
>
> Another bit of the solution is probably to introduce a separate
> SELinux policy for libguestfs itself. No, sorry, I can't volunteer for
> that right now. :(
>
> --
> Stefano
>


-- 
Thanks,

Yumei Huang

Re: [PATCH] test: Update README.md

[Richard W.M. Jones]

On Wed, Sep 24, 2025 at 12:00:04PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 24, 2025 at 11:31:31AM +0100, Richard W.M. Jones wrote:
> > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:
> > > And now that you say that, I just realised that it would be as simple
> > > as:
> > > 
> > >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > > 
> > >   LIBGUESTFS_BACKEND=direct virt-edit...
> > 
> > While that will indeed work, we're trying to discourage people from
> > doing that, since it removes the other good things that libvirt does,
> > such as setting up SELinux.
> > 
> > The real solution here IMHO is for libvirt to make session mode work
> > for root without changing UID.  It actually goes out of its way to
> > stop this working at the moment[1].
> 
> We made it possible to run QEMU as root:root while still using
> system mode quite a while ago now. It requires adding this
> to the XML:
> 
>   <seclabel type='static' model='dac' relabel='yes'>
>     <label>+0:+0</label>
>   </seclabel>

We don't currently use this.  I have filed a bug:

  https://issues.redhat.com/browse/RHEL-117440

> AFAICT, the resulting QEMU will also still have all capabiltiies
> set, most importantly CAP_DAC_OVERRIDE.  So unless I'm missing
> something there shouldn't be anything that can't be done with
> system mode, that a session mode would allow.
> 
> I thought I had already suggested that libguestfs use this
> seclabel, but don't recall if it was ever tried, or if we
> hit some other roadblock.
> 
> > [1] In qemuStateInitialize -> virQEMUDriverConfigNew, I think
> 
> Well that's where the initial control is, but it isn't a simple as just
> removing/changing that code. When running as root, we have access to a
> lot of system wide resources, and libvirt needs to track which are in
> use by VMs or not. We can't do that tracking if we have two separate
> privileged daemons for both system mode and a root-session mode.
> 
> It might be possible to have a single daemon service both roles. VMs
> defined via a session mode connection would auto-add the above
> <seclabel> to default to running as root. It would also need to
> dynamically change what's reported in capabilities to reflect this
> different default, and more systemd socket unit files at the locations
> that the session mode client app looks for.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top