On Tue, Sep 23, 2025 at 2:36 PM Yumei Huang wrote: > > On Tue, Sep 23, 2025 at 4:03 AM Stefano Brivio wrote: > > > > On Mon, 22 Sep 2025 11:03:23 +0800 > > Yumei Huang wrote: > > > > > On Fri, Sep 19, 2025 at 5:58 PM Stefano Brivio wrote: > > > > > > > > On Fri, 19 Sep 2025 09:43:29 +0800 > > > > Yumei Huang wrote: > > > > > > > > > Signed-off-by: Yumei Huang > > > > > --- > > > > > 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 ; > > > > 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