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=PBEYr3F2; 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 B66EE5A0271 for ; Wed, 24 Sep 2025 11:09:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758704956; 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=ZcYA3j51vdnQBqElkZMXrrZ96sGLYEdy6jmzY2ma+CY=; b=PBEYr3F2sqVL5t4NI/EjJFcs4U9vM+zV7JtZKeOjJxc3OTnEEGR2ON6jI4mKQF/nrEzuV7 K0cpE2gM74cTBY1pkAOan/zRST8EK6XmrhiFYxsu/KmI7UnOKCqqyg1j3bzesv7kzKuBGr s+BL5I6zsDPhrEX2RIX5TSZxpHWROxc= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-325-63L0baR0PKuas9sxbd8_HQ-1; Wed, 24 Sep 2025 05:09:14 -0400 X-MC-Unique: 63L0baR0PKuas9sxbd8_HQ-1 X-Mimecast-MFC-AGG-ID: 63L0baR0PKuas9sxbd8_HQ_1758704954 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-46cde0b2226so14740095e9.2 for ; Wed, 24 Sep 2025 02:09:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758704953; x=1759309753; 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=GEweqR1I8b3/r4l0f59T+tLCy1P3IDngDyNf2Y0/lXc=; b=XJ334GE2GqlcZyhh+0UsyzZNcZ0s9nf2oL5gozXu29z/MypXyrxMpATdGQuUhQ7XqL LKmWsu/Bw4xZinbQemI6UUrvMiil1vfTwlp23bCXCSpEAg3dpN0t90KEZYNVpEz2axW7 lDrCHzAZPWthDC4A9h2qyPLqOI4y1vSh+fEMUz2zwaof4K0LvJswI63VlAK6WsOkHsBz nMB5RIjj/nmFIeYoX+TAOusAb52XNR0Iz6Nkt07Ezsz2MLRjFfKRDhNoiUaFZlylZFCU wndfWe9nglLhbSAZz+KK0MZZRvQlIysQMf3+cyw2d3kHimeAh4JZj8UM7VbutUs6HGhF zxkg== X-Forwarded-Encrypted: i=1; AJvYcCXKlSGMb+fV4IYO9WuDUYBcsCcxS0zoOpuocyicQZrKbD2BQFiPxlakjVrEKfhuf+VLyl5+wzfE698=@passt.top X-Gm-Message-State: AOJu0YwLc39BT2pzT9xnUqct0eiLmIKZpCkceQXmDcMMij9S5LmzhroV QGkyCWZsLYcbbbMAGOu/i4XqJl2RxOEVyCjlaP0L2nh4Iim4Vd9YZD+se5dzuw7Mbj0d/5bv5hc VXMwUf/9FS1eOOohsbaM0qNPdcoG4JQ9Qfncc7AxaIRty3rxtKKwfTp6v/Vz3Ng== X-Gm-Gg: ASbGncu5zWodsW40JwRkJc3SAa5iEJ+c/DAYUUwz64b9XWjXg62OLloiU7e9B5iSXm6 WhEX7W1uJZ4cnQcrorzugnQWEp5IzN3lffaTFpHrq/BlNBX0fF6KCSR/u0WEiMpFdqMCQaoOO2O 2BXyTjoPbyBG1lRQYsNBaMRrOObSIkK2lV17UKcJsNenW0rdgJiQwMXtWS4ZY1sCO6T5TLAY34Z Ttfta5nB4K6M6gJwgxwnppoKMpDcw3EwbbCdaJzdY2q0yhp0GKZ1kT92MXUFb+QjEO3HW9XnN+I ajkBOc4XEp9Ews2OPJ+5Y8ptODnvSkVMZt8HgiS6Ey1/O0gCvgNEnR6sXjbyhA1jdTkg X-Received: by 2002:a05:600c:4713:b0:456:1560:7c5f with SMTP id 5b1f17b1804b1-46e1da9f865mr49985285e9.14.1758704952515; Wed, 24 Sep 2025 02:09:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH/ySkWGXVgJ6Sh5ogF2A2yMXYT6IlJZOAcibPTj4HcwRjQTbujLm2hpWPrp2fwkhCvSWlxBw== X-Received: by 2002:a05:600c:4713:b0:456:1560:7c5f with SMTP id 5b1f17b1804b1-46e1da9f865mr49984745e9.14.1758704951770; Wed, 24 Sep 2025 02:09:11 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46e2a998309sm23031695e9.4.2025.09.24.02.09.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Sep 2025 02:09:11 -0700 (PDT) Date: Wed, 24 Sep 2025 11:09:09 +0200 From: Stefano Brivio To: "Richard W.M. Jones" Subject: Re: [PATCH] test: Update README.md Message-ID: <20250924110909.43a16cfa@elisabeth> In-Reply-To: <20250924085621.GT1460@redhat.com> References: <20250919014329.6007-1-yuhuang@redhat.com> <20250919115822.4e3aab21@elisabeth> <20250922220338.49013fce@elisabeth> <20250923123213.61ddd9d5@elisabeth> <20250924104632.75b3f5a8@elisabeth> <20250924085621.GT1460@redhat.com> 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: kuCQkBR41jEZ4zVoaaBbzo4Dny8wxcfMlvY4UB4wS2U_1758704954 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: MYKNOTW4WFYXUOMZL2ORAAHMMXEHCRH4 X-Message-ID-Hash: MYKNOTW4WFYXUOMZL2ORAAHMMXEHCRH4 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: Yumei Huang , passt-dev@passt.top, david@gibson.dropbear.id.au, berrange@redhat.com 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 Wed, 24 Sep 2025 09:56:21 +0100 "Richard W.M. Jones" wrote: > On Wed, Sep 24, 2025 at 10:46:32AM +0200, Stefano Brivio wrote: > > [Cc'ing Rich... Rich, see my first question below] > >=20 > > On Wed, 24 Sep 2025 09:58:57 +0800 > > Yumei Huang wrote: > > =20 > > > On Tue, Sep 23, 2025 at 6:32=E2=80=AFPM Stefano Brivio wrote: =20 > > > > > > > > On Tue, 23 Sep 2025 14:36:41 +0800 > > > > Yumei Huang wrote: > > > > =20 > > > > > On Tue, Sep 23, 2025 at 4:03=E2=80=AFAM Stefano Brivio wrote: =20 > > > > > > > > > > > > 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 D= ebian-based distributions: > > > > > > > > > git go iperf3 isc-dhcp-common jq libgpgme-dev libsec= comp-dev linux-cpupower > > > > > > > > > lm-sensors lz4 netavark netcat-openbsd psmisc qemu-e= fi-aarch64 > > > > > > > > > qemu-system-arm qemu-system-misc qemu-system-ppc qem= u-system-x86 > > > > > > > > > - qemu-system-x86 sipcalc socat strace tmux uidmap val= grind > > > > > > > > > + sipcalc socat strace tmux uidmap valgrind > > > > > > > > > > > > > > > > > > NOTE: the tests need a qemu version >=3D 7.2, or one tha= t contains commit > > > > > > > > > 13c6be96618c ("net: stream: add unix socket"): this chan= ge 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 requir= ed assets: > > > > > > > > > + > > > > > > > > > + cd test > > > > > > > > > + make assets > > > > > > > > > + > > > > > > > > > +Then issue: > > > > > > > > > > > > > > > > > > ./run > > > > > > > > > > > > > > > > > > @@ -91,6 +96,28 @@ variable settings: DEBUG=3D1 enables d= ebugging messages, TRACE=3D1 enables tracing > > > > > > > > > > > > > > > > > > PCAP=3D1 TRACE=3D1 ./run > > > > > > > > > > > > > > > > > > +**Note:** > > > > > > > > > + > > > > > > > > > +* It's recommended to run the commands as a non-root use= r. > > > > > > > > > + Due to [Bug 967509](https://bugzilla.redhat.com/show_b= ug.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 i= ncorrectly point to > > > > > > > > > + `/run/user/0` instead of `/run/user/ID`, which can cau= se error. =20 > > > > > > > > > > > > > > > > Thanks for the research, I wasn't aware of that, and recent= ly 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 we= re working > > > > > > > > with 'machinectl shell' instead. > > > > > > > > > > > > > > > > At the same time: running this whole stuff as root sounds r= ather crazy, > > > > > > > > unless it's a throw-away VMs with absolutely nothing import= ant on it. > > > > > > > > > > > > > > > > That is, regardless of the issue with XDG_RUNTIME_DIR. I wo= uld 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 ... > > > > > > > > =20 > > > > > > > > > + **Workaround:** Log out and log back in as the intende= d user to ensure the > > > > > > > > > + correct runtime directory is set up. =20 > > > > > > > > > > > > > > > > We could also suggest 'machinectl shell' if it's really nee= ded for > > > > > > > > whatever reason. =20 > > > > > > > > > > > > > > I'm not sure how 'machinectl shell' works here. The error hap= pens when > > > > > > > running 'make assets', > > > > > > > which calls 'prepare-distro-img.sh' script, which calls 'virs= h 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-amd6= 4.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 t= his: > > > > > > > > > > > > > > ./prepare-distro-img.sh prepared-debian-8.11.0-openstack-amd6= 4.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-amd= 64.qcow2] Error 1 > > > > > > > > > > > > > > Do you mean to run 'make assets' with 'machinectl shell'? Wha= t'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. =20 > > > > > > > > > > > > No, I mean using 'machinectl shell' instead of 'su' (it's inten= ded as a > > > > > > replacement), that is: > > > > > > > > > > > > $ machinectl shell > > > > > > # make assets > > > > > > > > > > > > ...because that one will set XDG_RUNTIME_DIR. =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 abov= e. =20 > > > > > > > > Can one need specify a XDG_RUNTIME_DIR that actually exists, maybe? > > > > Does that work? =20 > > >=20 > > > I guess I need to clarify the issues more clearly. > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > 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] > > >=20 > > > Switching the user with 'machinectl shell --uid=3D$user' can solve th= e issue. > > >=20 > > > 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. > > >=20 > > > 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] =20 > >=20 > > Ah, look, UID 107 is usually QEMU on Fedora / RHEL, so libguestfs is > > switching to that. > >=20 > > But it shouldn't, because then it won't be able to access the images > > you downloaded as root. > >=20 > > Rich, do you know why it happens? =20 >=20 > 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: >=20 > https://bugzilla.redhat.com/show_bug.cgi?id=3D1045069 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=3Ddirect 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 ever= y > > > directory under /run/user. I guess the problem here is that we just > > > can't run 'virsh edit' as root. =20 > >=20 > > Wait, it's not 'virsh edit', it's 'virt-edit', and it's not true that > > you can't run it as root. > >=20 > > We had explicit reports from libguestfs (virt-edit is part of it, and i= t > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > See: > >=20 > > https://issues.redhat.com/browse/RHEL-36045 > >=20 > > 45b8632dcc0e ("conf: Don't lecture user about starting us as root") > >=20 > > c9b241346569 ("conf, passt, tap: Open socket and PID files before swi= tching UID/GID"). > > =20 > > > > > Maybe we can just put it like: > > > > > > > > > > Running the commands as root is just not allowed. If you log= in > > > > > the system with root, don't use su to switch users due to [Bug > > > > > 967509](https://bugzilla.redhat.com/show_bug.cgi?id=3D967509). Lo= g out > > > > > and log back in as the intended user, or use 'machinectl shell > > > > > --uid=3D$user'. > > > > > > > > > > What do you think? =20 > > > > > > > > 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 yo= u > > > > don't actually have other users (it happens with some VM images or > > > > in embedded systems), so 'machinectl shell --uid=3D$user' won't rea= lly > > > > help there. =20 > > >=20 > > > 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). =20 > >=20 > > It's not so important for our tests, but it would be good to know why > > it breaks, in general. > > =20 > > > The workaround proposed is > > > just for those who login with root and switch to a non-root user to > > > run the tests. > > > =20 > > > > > > > > Maybe just mention setting XDG_RUNTIME_DIR to whatever is appropria= te > > > > (does /tmp work?)? > > > > =20 > > > > > > > > > +* 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 Fedor= a in a > > > > > > > > namespace (which we should really fix, I can look into it i= f you share > > > > > > > > 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 ve= ry 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:D= EBUG:DEBUG: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 ] < fail= ed. > > > > > > > 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 a= ddresses > > > > > > 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 event= ually > > > > > > we'll want to have tests with DHCP clients in unprivileged setu= ps also > > > > > > as part of Fedora automated tests, and I'm fairly sure that tho= se run > > > > > > with SELinux in enforcing mode. So we should really fix this. = =20 > > > > > > > > > > Sure, I will file a ticket for that. =20 > > > > > > > > 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 iss= ues > > > > there. I guess we should try things out and send a merge request. = =20 > > > > > > Agree. Let's just disable it temporarily to bypass the issue. =20 > >=20 > > 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. > >=20 > > 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. > > =20 > > > > > > By the way, it would also be interesting to see if, once the te= st suite > > > > > > gets past this point, you get further messages in audit.log. > > > > > > > > > > > > If you do 'setenforce 0', SELinux switches to the so-called "co= mplain > > > > > > mode", and warnings are still logged, but they won't block anyt= hing. > > > > > > > > > > > > So, with 'setenforce 0', we can find out from audit.log if we w= ould hit > > > > > > further failures. =20 > > > > > > > > > > Here is the audit.log: > > > > > > > > > > https://privatebin.corp.redhat.com/?49fef5ef2e766c42#Fki5LnD9EGMf= DDpmvFPp1WqGbQPwQk4qQmQbmKugDLxb > > > > > > > > > > From what I can see, there is no 'avc: denied' after the dhcp ca= ses. =20 > > > > > > > > [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 --=20 Stefano