From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RZCmG9lz; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id E34985A026F for ; Wed, 24 Sep 2025 03:59:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758679157; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ppVx+y0RchcQN02ToTMPcsP1S2GmHGQYiUOQVlFgSCg=; b=RZCmG9lz/A3SORDxifC2T/bGoWwkbFcVgL4uwfXHoLqRdwQ2j4fu8kExGG5koLopjHc9o7 BCg5gWdW8ypqmJNnmIribFzvz7BdJOpTnvacVc4Bxn1ir5jc6vc98I/iPAprJ+fTOLl44k o1Xl8LYMDy8lJmLiTINuAREiGRgSbdc= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-136-tmMXairnPVWnN9F9_wObgA-1; Tue, 23 Sep 2025 21:59:10 -0400 X-MC-Unique: tmMXairnPVWnN9F9_wObgA-1 X-Mimecast-MFC-AGG-ID: tmMXairnPVWnN9F9_wObgA_1758679149 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-62fce1f3fa8so4094407a12.3 for ; Tue, 23 Sep 2025 18:59:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758679149; x=1759283949; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ppVx+y0RchcQN02ToTMPcsP1S2GmHGQYiUOQVlFgSCg=; b=OqboJcygWZvMttb9kGELdZgQ1dXdzJnp2x/2HqGblWhndD4Gx+fnSJ6iYngR8LNKdG aWlNm7giRIxyBF2ctgsQDC1jN0vpyRax22F9GXgJnoI6sQci7V2UVNwSbsu/9JyV8xuK cOocTA5FbEA94h+/bub+uqLzrqUXuyfJGbtC0mYuIEIo2fnj0vxHl8OdeKGRhdPA2Joi JZq0UWwHL4m6rdkLPCUnJjHecNdyVBfRLGFHVD8Bhnil8wUs3in9aE1D0h0udFw033Bm 2C0HJzbbAmWeJkzNhPoOsrVf9tP2rmh23dMQM1GYI7I1wE6nOZSOi3C5fRAVSRZHkizj sIog== X-Gm-Message-State: AOJu0YyQAAS9lwkLZs2yzP6y3IRFkWSD5p08d6kAyRinQwPNBsc/0qNu E2K4lLc/kqvPGlUmvKIVg3fx5G0tC9fTBLWUIHoMgSTj5MPA1M7l7KCp6KhDND+46zhczc+YK8P r3Xdl78dlCX9qs7YycluX2R/WUO3GXvJeiGbvYVtTNUy4VPO8z98QLXJfP+Afn2bTYT7TzsRlPp g9u/OtHPr6gX7g5MBQdwZvDGtNbhMpvtZrsJOiscQ= X-Gm-Gg: ASbGnct/Mj1LgC8c69uNd2Nu7Pi59e0JalpGH5rX7Re5+794fWm8LU86t5HdqEBLeDr aKV8/OlTiY8yRedHV0TVv/iAn2vfknlIUEFE2UTNBiFmRmW9OadMVC9jjuApAOvQMnDtI1dnnA8 czZtUhqSXionA3KHqn722C0g== X-Received: by 2002:a05:6402:3059:b0:62f:c1c0:d6f with SMTP id 4fb4d7f45d1cf-6346767c497mr3618028a12.8.1758679148779; Tue, 23 Sep 2025 18:59:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFc0xJPRLw0Bl8V/rkyvWJi2b5lciVixyYeOrW7YF+gVBcF71VQr3FLz+KzlzB0SYJBbvjWwnQFdJCZFzkacXs= X-Received: by 2002:a05:6402:3059:b0:62f:c1c0:d6f with SMTP id 4fb4d7f45d1cf-6346767c497mr3618010a12.8.1758679148313; Tue, 23 Sep 2025 18:59:08 -0700 (PDT) MIME-Version: 1.0 References: <20250919014329.6007-1-yuhuang@redhat.com> <20250919115822.4e3aab21@elisabeth> <20250922220338.49013fce@elisabeth> <20250923123213.61ddd9d5@elisabeth> In-Reply-To: <20250923123213.61ddd9d5@elisabeth> From: Yumei Huang Date: Wed, 24 Sep 2025 09:58:57 +0800 X-Gm-Features: AS18NWA1DDiuy8H3tfm8BQIbwgfZJRJ0ygduC5Y6k00IfVjAZq0X40eIIG4cBwA Message-ID: Subject: Re: [PATCH] test: Update README.md To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 4n50Pzpoi8dQXdWzOko_1XYVIbZkyPDa21gIP_q525w_1758679149 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: LZUJXQA4OUFSTGXTXEISO3E7K3HVEB62 X-Message-ID-Hash: LZUJXQA4OUFSTGXTXEISO3E7K3HVEB62 X-MailFrom: yuhuang@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, david@gibson.dropbear.id.au X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Sep 23, 2025 at 6:32=E2=80=AFPM Stefano Brivio = wrote: > > On Tue, 23 Sep 2025 14:36:41 +0800 > Yumei Huang wrote: > > > On Tue, Sep 23, 2025 at 4:03=E2=80=AFAM Stefano Brivio wrote: > > > > > > On Mon, 22 Sep 2025 11:03:23 +0800 > > > Yumei Huang wrote: > > > > > > > On Fri, Sep 19, 2025 at 5:58=E2=80=AFPM 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-d= ev linux-cpupower > > > > > > lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aar= ch64 > > > > > > qemu-system-arm qemu-system-misc qemu-system-ppc qemu-syst= em-x86 > > > > > > - qemu-system-x86 sipcalc socat strace tmux uidmap valgrind > > > > > > + sipcalc socat strace tmux uidmap valgrind > > > > > > > > > > > > NOTE: the tests need a qemu version >=3D 7.2, or one that cont= ains commit > > > > > > 13c6be96618c ("net: stream: add unix socket"): this change int= roduces support > > > > > > @@ -81,7 +81,12 @@ The following additional packages are common= ly needed: > > > > > > > > > > > > ## Regular test > > > > > > > > > > > > -Just issue: > > > > > > +Before running the tests, you need to prepare the required ass= ets: > > > > > > + > > > > > > + cd test > > > > > > + make assets > > > > > > + > > > > > > +Then issue: > > > > > > > > > > > > ./run > > > > > > > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=3D1 enables debuggi= ng messages, TRACE=3D1 enables tracing > > > > > > > > > > > > PCAP=3D1 TRACE=3D1 ./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=3D967509), > > > > > > + if you switch users with `su` or `sudo`, the directory `/run= /user/ID` may > > > > > > + not be created. In that case, `XDG_RUNTIME_DIR` will incorre= ctly point to > > > > > > + `/run/user/0` instead of `/run/user/ID`, which can cause err= or. > > > > > > > > > > Thanks for the research, I wasn't aware of that, and recently spe= nt > > > > > 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 wor= king > > > > > 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 ma= ybe > > > > > 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 fo= r > > > > > whatever reason. > > > > > > > > I'm not sure how 'machinectl shell' works here. The error happens w= hen > > > > 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.qcow= 2 > > > > 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=3D38 int1=3D13] > > > > > > > > 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.qcow= 2 > > > > libvirt: XML-RPC error : Cannot create user runtime directory > > > > '/run/user/0/libvirt': Permission denied > > > > libguestfs: error: could not connect to libvirt (URI =3D > > > > qemu:///session): Cannot create user runtime directory > > > > '/run/user/0/libvirt': Permission denied [code=3D38 int1=3D13] > > > > make: *** [Makefile:115: prepared-debian-8.11.0-openstack-amd64.qco= w2] Error 1 > > > > > > > > Do you mean to run 'make assets' with 'machinectl shell'? What's th= e > > > > exact cmd here? I tried this, seems not work. > > > > > > > > # machinectl shell --uid=3D$(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 =3D qemu:///session): Cannot create user runtime directory '/run/user/0/libvirt': Permission denied [code=3D38 int1=3D13] Switching the user with 'machinectl shell --uid=3D$user' can solve the issu= e. 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=3D38 int1=3D13] 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=3D967509). Log out > > and log back in as the intended user, or use 'machinectl shell > > --uid=3D$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=3D$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 avo= id 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 y= ou 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 fir= st > > > > few tests, other tests haven't been executed. > > > > > > > > =3D=3D=3D pasta/dhcp > > > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:D= EBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:> > > > > Interface name > > > > DEBUG:DEBUG:? [ -n "eno8303" ] > > > > DEBUG:DEBUG:...passed. > > > > > > > > > DHCP: address > > > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ =3D 10.72.136.30 ] < failed. > > > > DEBUG:DEBUG:...failed. > > > > > > > > > DHCP: route > > > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ =3D 10.72.139.254 ] < failed. > > > > DEBUG:DEBUG:...failed. > > > > > > > > > DHCP: MTU > > > > DEBUG:DEBUG:? [ 1500 =3D 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 address= es > > > and routes via ip(8), even though it's in a detached namespace and th= at > > > 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 als= o > > > 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 sui= te > > > 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 h= it > > > further failures. > > > > Here is the audit.log: > > > > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvF= Pp1WqGbQPwQk4qQmQbmKugDLxb > > > > 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 > --=20 Thanks, Yumei Huang