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=QHi7vemh; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 93EEB5A026F for ; Tue, 23 Sep 2025 12:32:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758623544; 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=Ak6fHTfy2JVB2DyXNUDquI27Q+NOJnG1Qug6t9F3EMU=; b=QHi7vemhyLXgdnBFtJobE+i41/k/xNU9h89w2mL5mz2vcNnTLfI28Zxvejwhoa78xRciPE vFFaq1tbog6U4R3OYbMLzKz8rdyynLnThdwBp+zN+k1b8Zxi0vqPiiW16N0KERJNKJwaHr fkXmxoJQPe1GQE6oVelptcYIRvgrIKA= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-549-tFMRezslN4SwJcsz3xcyzA-1; Tue, 23 Sep 2025 06:32:22 -0400 X-MC-Unique: tFMRezslN4SwJcsz3xcyzA-1 X-Mimecast-MFC-AGG-ID: tFMRezslN4SwJcsz3xcyzA_1758623541 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3ece0cb7c9cso4466243f8f.1 for ; Tue, 23 Sep 2025 03:32:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758623541; x=1759228341; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=tOw2F730bJUhjv9CSLG/0Ffy0NnyHtiHEgKqjjjBFfI=; b=YBvBgJhF28zS9MJUXmFprQMOxxUFHUocA4L6tGI1lk1sGV77TY2DuekyNY5t+nqsJh M/TUxbaanJvcb6jER8MAjUm88KStnjFlZ2C1AG3M7Q0yYI+3mVWf/glQXuJ3IB2dBe10 pO/JSoCzcJ17I0bam0AkqLQlKWXPY08j5zEDquseJyLcE79EP5uWki/kTe/x9N8cxec6 F69I/Q0Bs7ZBruXm8KAar5voOzQxZaXEc9PvAtz/qdSO3Z95TG2p7mQ6MoRkaI2GKbDq Sw+Xh1j5nZjq9BjDealYjKXc4IXqg1U370D47HQUgxU5MJRv0T4MUVJZvMMk+n9ibNMq SNeg== X-Gm-Message-State: AOJu0YxbuOsubdQ1UEU1Ybi4pLJD+LfNQVInB6OpQ9LUfKwOpyi2jCtn C+342hrkCywzat6ipZZxfSc2eGQz+xuYeuhkEWJc7JMDFaeHxARjN1wmBZDNI3uMtfaV66u0V0R nBJG5GIlKbWbb/wsEIpQnj6N8S3sqMwbLyHUQ2JyoKntzUEEwFFmjrg== X-Gm-Gg: ASbGnctBo5hLXuNUTTM8FnHx448CtdO9ymSoVEB+LDhdp2IKO5BFcPsNuVFCtok0Ry9 NNWTGjRgTbPRzSXhoU0AW0l83fGYucKASkxkWk/TolQ70KAEYzRYANyfLoXrg3oOyYYo03PUXqt od4p6ikeTPhBs1K7+mrsds26ub8aG0wdhua7UJR/LF42hCNVlM5yOAN63XYWXVUqQiawxyUBa2J Lt9pDMRKBYFzlTgyqHEDm+889JaaqU/w6uhf+yxU87B+1pRGm5PX9+S8FrmGkVKx8k2ZqT62/AV X+wp9ssuJemOtpCpSJD734hyL9iTueK9rxcZNMOctb4rvWwaeGU= X-Received: by 2002:a05:6000:2388:b0:3fa:944b:9bc3 with SMTP id ffacd0b85a97d-405ccae17a4mr2010418f8f.62.1758623541230; Tue, 23 Sep 2025 03:32:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGjRZyyMzwL/Jo6jjU2h9xXypgekVGESNwzifKDKJ1g34PwwgpRdpXLWBSlFHvUGm7/HVmeWw== X-Received: by 2002:a05:6000:2388:b0:3fa:944b:9bc3 with SMTP id ffacd0b85a97d-405ccae17a4mr2010379f8f.62.1758623540532; Tue, 23 Sep 2025 03:32:20 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46de4d67625sm66144385e9.16.2025.09.23.03.32.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Sep 2025 03:32:19 -0700 (PDT) Date: Tue, 23 Sep 2025 12:32:13 +0200 From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH] test: Update README.md Message-ID: <20250923123213.61ddd9d5@elisabeth> In-Reply-To: References: <20250919014329.6007-1-yuhuang@redhat.com> <20250919115822.4e3aab21@elisabeth> <20250922220338.49013fce@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: nshbXp7G0setFbMqvR2ZSoDJScGOdQfvpM3nbtARSFc_1758623541 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: HJOKZ5H4WPWLGNJUY6PT57BL3ZUR2NT3 X-Message-ID-Hash: HJOKZ5H4WPWLGNJUY6PT57BL3ZUR2NT3 X-MailFrom: sbrivio@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, 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: > > =20 > > > On Fri, Sep 19, 2025 at 5:58=E2=80=AFPM Stefano Brivio wrote: =20 > > > > > > > > On Fri, 19 Sep 2025 09:43:29 +0800 > > > > Yumei Huang wrote: > > > > =20 > > > > > 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-ba= sed distributions: > > > > > git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev= linux-cpupower > > > > > lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch= 64 > > > > > 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 >=3D 7.2, or one that contai= ns commit > > > > > 13c6be96618c ("net: stream: add unix socket"): this change intro= duces 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 asset= s: > > > > > + > > > > > + cd test > > > > > + make assets > > > > > + > > > > > +Then issue: > > > > > > > > > > ./run > > > > > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=3D1 enables debugging= 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?i= d=3D967509), > > > > > + if you switch users with `su` or `sudo`, the directory `/run/u= ser/ID` may > > > > > + not be created. In that case, `XDG_RUNTIME_DIR` will incorrect= ly point to > > > > > + `/run/user/0` instead of `/run/user/ID`, which can cause error= . =20 > > > > > > > > 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 worki= ng > > > > with 'machinectl shell' instead. > > > > > > > > At the same time: running this whole stuff as root sounds rather cr= azy, > > > > unless it's a throw-away VMs with absolutely nothing important on i= t. > > > > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I would mayb= e > > > > make the wording stronger, something like: > > > > > > > > * Don't run the tests as root, it's not needed! > > > > * If you really need to, note that ... > > > > =20 > > > > > + **Workaround:** Log out and log back in as the intended user t= o ensure the > > > > > + correct runtime directory is set up. =20 > > > > > > > > We could also suggest 'machinectl shell' if it's really needed for > > > > whatever reason. =20 > > > > > > I'm not sure how 'machinectl shell' works here. The error happens whe= n > > > running 'make assets', > > > which calls 'prepare-distro-img.sh' script, which calls 'virsh edit'.= =20 > > > > Ah, I didn't know! So this is actually similar to > > https://issues.redhat.com/browse/RHEL-70222. > > =20 > > > 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=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.qcow2 > > > 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.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=3D$(id -u pat) .host > > > /home/test/passt/test/make assets > > > Connected to the local host. Press ^] three times within 1s to ex= it session. > > > > > > Connection to the local host terminated. =20 > > > > 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. =20 >=20 > 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: >=20 > 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'. >=20 > 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. 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 =20 > > > > > > > > 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 sh= are > > > > the messages you're getting from /var/log/audit/audit.log), did you= hit > > > > any other issue with it? > > > > =20 > > > > > > 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. > > > > > > =3D=3D=3D pasta/dhcp =20 > > > DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:DEB= UG:DEBUG:DEBUG:DEBUG:DEBUG:DEBUG:> =20 > > > Interface name > > > DEBUG:DEBUG:? [ -n "eno8303" ] > > > DEBUG:DEBUG:...passed. > > > =20 > > > > DHCP: address =20 > > > DEBUG:DEBUG:DEBUG:DEBUG:? [ @EMPTY@ =3D 10.72.136.30 ] < failed. > > > DEBUG:DEBUG:...failed. > > > =20 > > > > DHCP: route =20 > > > DEBUG:DEBUG:DEBUG:? [ @EMPTY@ =3D 10.72.139.254 ] < failed. > > > DEBUG:DEBUG:...failed. > > > =20 > > > > DHCP: MTU =20 > > > DEBUG:DEBUG:? [ 1500 =3D 65520 ] < failed. > > > DEBUG:DEBUG:...failed. > > > =20 > > > > DHCPv6: address =20 > > > DEBUG: =20 > > > > 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. =20 >=20 > 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. =20 >=20 > Here is the audit.log: >=20 > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMfDDpmvFPp= 1WqGbQPwQk4qQmQbmKugDLxb > > 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. --=20 Stefano