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=Bw+OETg6; 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 AA7535A026F for ; Tue, 23 Sep 2025 08:36:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758609417; 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=Gf3y2Femj/Ki87qlXsfMjYgGSNE5eIzWAEdVaGuy8+s=; b=Bw+OETg6SpYBg67skUbuZlkpDDmVLJy/H6E9GsRLGcPc9kUoBmWUannXNkpUfH6g4qk3Eb hJg7XwCg5M0qBSFk7Fl2LsQLEQyweG7yLlwhAYUdy1Tdo81vOOxjpQU46sgl4d+5QWK92K DdXvfn6o/NjdEQeG5CU4FMd712nwcOE= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-SwRADyKtPn2-TJqsj-aTHg-1; Tue, 23 Sep 2025 02:36:55 -0400 X-MC-Unique: SwRADyKtPn2-TJqsj-aTHg-1 X-Mimecast-MFC-AGG-ID: SwRADyKtPn2-TJqsj-aTHg_1758609415 Received: by mail-ed1-f71.google.com with SMTP id 4fb4d7f45d1cf-631dbb59345so4106166a12.3 for ; Mon, 22 Sep 2025 23:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758609414; x=1759214214; 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=Gf3y2Femj/Ki87qlXsfMjYgGSNE5eIzWAEdVaGuy8+s=; b=KNPTbHLclHjKU3/HPe8sP4Swfv4w8ZKLAAFUIL2ISzm57BN4x2NsSUUO8QX8wIRIG4 aZCcCm3HfWMHj/oUJwdOOgwQmHBLB9p5AG7o+FyNsEah1uavR0KoFqiA0scNlAti7SHP HT7kN09nwYpN57UF7Gjybjn6e8FOEVL72dpiGbklDvr4p2WKqy0YTIk/oI2dF/NMOqqC mIRXVyGm5LP2/3t58kY8vp4wl8JhAwDoSIegWearEPuk5BL/BQvb3jF/i3q3QrOXJrOQ 9ILfWMDWojNeFp2tm94cjjOdOo1pk/KD+2Rfl0IolldZPhXKoGhqWibvMujPIElZPzod CwNA== X-Gm-Message-State: AOJu0Yw1VF2ucO+Zk7bZUOHothluyZ4q/j6d3JGsa2hmUBvIXgXkml+s shKAANC5pXWLIsjlXVS5eS7en72rAEyOeRqsgp1HKDQ/yl01fOFvuBPF/TY8rlZnhvY2+fZ582f WqwXdVA9lXuK87kfq7LHSZwav+ZtDggYrf/QkJ7BmF9rL5dS7IhxtqZ8DE2ZxVcxAdYP6jJdPRv yJXXk4wa4WS9DT08HeFb01svaqF2yQ97u1plpiGAs= X-Gm-Gg: ASbGncsJ97uHmMOzP4ciNkftFBkOG/XgEld9x64itKwAMR6qcKhdOM45tV5hj3d2YyY uq6Rlz27oDB81DUcr8WDdn5dvdqOSgYFq15WaXJeeS9j+bjlRgYYsflvmw38Jzp6AylCK/BnWXy R5K3ITkIyDeNWT7Duf8ca05g== X-Received: by 2002:a05:6402:2103:b0:62f:8274:d6bd with SMTP id 4fb4d7f45d1cf-63467678df9mr1347558a12.8.1758609414306; Mon, 22 Sep 2025 23:36:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFYunT1TOJc0pjTuHPNjSIvBfNF49dm8+IHFtpENcFrH2qc/g7WSK7aiyEqyWBchCLBSHHk6ITP/kaQVvTLjlo= X-Received: by 2002:a05:6402:2103:b0:62f:8274:d6bd with SMTP id 4fb4d7f45d1cf-63467678df9mr1347472a12.8.1758609412697; Mon, 22 Sep 2025 23:36:52 -0700 (PDT) MIME-Version: 1.0 References: <20250919014329.6007-1-yuhuang@redhat.com> <20250919115822.4e3aab21@elisabeth> <20250922220338.49013fce@elisabeth> In-Reply-To: <20250922220338.49013fce@elisabeth> From: Yumei Huang Date: Tue, 23 Sep 2025 14:36:41 +0800 X-Gm-Features: AS18NWDhe3pRNqxDMLqcMI75hsT8RgPXjVZQgq-ycNSLEXf5PV1DReucRfR7KdE Message-ID: Subject: Re: [PATCH] test: Update README.md To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: VoJxKKFSiI04kCS_5CICU25-n0rU6JjoG_WGPPUPJdw_1758609415 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RJYHF724OS2H3YVVN4LKS4OMT5VC72VJ X-Message-ID-Hash: RJYHF724OS2H3YVVN4LKS4OMT5VC72VJ 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 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-base= d distributions: > > > > git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev l= inux-cpupower > > > > lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64 > > > > qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x= 86 > > > > - 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 contains= commit > > > > 13c6be96618c ("net: stream: add unix socket"): this change introdu= ces support > > > > @@ -81,7 +81,12 @@ The following additional packages are commonly n= eeded: > > > > > > > > ## 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=3D1 enables debugging m= essages, 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/use= r/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 craz= y, > > > 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=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 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=3D967509). Log out and log back in as the intended user, or use 'machinectl shell --uid=3D$user'. What do you think? > > > > > +* SELinux may prevent the tests from running correctly. To avoid t= his, > > > > + 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 shar= e > > > the messages you're getting from /var/log/audit/audit.log), did you h= it > > > 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. > > > > =3D=3D=3D 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@ =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 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#Fki5LnD9EGMfDDpmvFPp1W= qGbQPwQk4qQmQbmKugDLxb >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 > --=20 Thanks, Yumei Huang