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=anRPBnqc; 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 726F15A0271 for ; Wed, 24 Sep 2025 13:48:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758714533; 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=H1ackZ9fSoPGk/7HWt1CTyB0GPhMvLO9dCyyZQIARmI=; b=anRPBnqcfFnIRRPEEEmFixaTR5oybkSVhvK2EQ+k3CXoL0V+3TwpKJE5rf1Aak6PT4D0V9 9ysMj5mW2AVj3GBawhXAWr4f0QCXzUK08XGEWvbhYTB2v7Whl/OpC84oWSaUjE6zIpYjl5 rKofq2fU/O3fnHKeyVYkKhFXdNykPCQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-341-6a4dx9P2Mnea2xr-Fp6tNQ-1; Wed, 24 Sep 2025 07:48:51 -0400 X-MC-Unique: 6a4dx9P2Mnea2xr-Fp6tNQ-1 X-Mimecast-MFC-AGG-ID: 6a4dx9P2Mnea2xr-Fp6tNQ_1758714530 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-45e05ff0b36so3991205e9.0 for ; Wed, 24 Sep 2025 04:48:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758714529; x=1759319329; 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=H1ackZ9fSoPGk/7HWt1CTyB0GPhMvLO9dCyyZQIARmI=; b=NFCMTR7E9yVlmGPkP6M7xx68f0QOh8zWfGAN1ts9e9W/bB6EADSpYIXgqHjdlF5OsE UDS5pDt2bc3VuLujoVa9o0qYU9T7F+kjRBX0EuRY63oi4zQGVSWBNMG7Fdg9yh7rEW23 2hJP1iHfarNGeHiicnMnHRuy10JEljNUmG7z8h9beesVQtkQ1MsDs1T/5ngGpTTh2DB9 jZ6jj6910RvoBqgSx6ZR/4gWNGbA9q267N57pSJ7oHB0Lc/muUv3XO4jq4Dt/Ydk38Z4 NNHyMglvIPX7VUhKG5qKlbANyf1k6Q+kty2hDOlGeNGQd2ROsEl9EIy1sqzYqe5WoY2U ZjbQ== X-Forwarded-Encrypted: i=1; AJvYcCXuq1iFgammiOS3CYUjqX7ncs+Vuc/P3ismS8UidIhR6Fbrpdl77ag7YQpy9gqIA4KX0FGOVW8/1Cc=@passt.top X-Gm-Message-State: AOJu0Yw/uFfPNlB3lkaE4bsXKNqdPjo99n3YfAVMyfyx1d60jPy5c1Jw Sw4i55eE/nLZJ/v53Dyb6fEvxmL6jhR8FN/e175k4hUDjA89iH9NUp5/wtObQc0acyH2GQp6v7Y 2gkU2MKiPExKgwYZ8vhunllm3WG1QJFuYt4DwxKoNTFuFbwTj5wDXag== X-Gm-Gg: ASbGncvJWVmurIPik9jQdcQ/R2sNpWjDkrYsDfXfqOaNIRqapuOvuQ/TxRIy0QKzyaH Tfgavg7yPDyxVrSXv/FsWvCxhb0nbIeNkwnNU9Y+7X834rwBxs99+ItHIAYVcIrPVXkVlNpXkY5 ErOlskcS3d8WGtWjdu4FQ7zN8+UhdzsUBb/nfK5xt3BerDiKo6DG3Uzxe6Mih2Mf6fm20tMCEXT oasC7aeMWW1Y2aRCmPTJlMW0CYrAmFmF9cQCcpwJjqg/NHBy2c5ZONM9APQ6Sxsw/kGwJ11gksI tB76sfJhJQZzi4xf/PmVuZH/N5IQeEPFMz6wRyb2zHXH2ifqIn4= X-Received: by 2002:a05:600c:4687:b0:45c:b6d3:a11d with SMTP id 5b1f17b1804b1-46e2b4fe0ffmr23704265e9.1.1758714529211; Wed, 24 Sep 2025 04:48:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEJllZi07K9f5px1FcKjP9Xw+8n0cQYUodwE9IGR0ogz3LhdpZj7vxYzx239lZrR1lR5b4KQg== X-Received: by 2002:a05:600c:4687:b0:45c:b6d3:a11d with SMTP id 5b1f17b1804b1-46e2b4fe0ffmr23704055e9.1.1758714528753; Wed, 24 Sep 2025 04:48:48 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46e2a996c03sm29078315e9.3.2025.09.24.04.48.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Sep 2025 04:48:47 -0700 (PDT) Date: Wed, 24 Sep 2025 13:48:46 +0200 From: Stefano Brivio To: "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" Subject: Re: [PATCH] test: Update README.md Message-ID: <20250924134846.7fbe534e@elisabeth> In-Reply-To: References: <20250922220338.49013fce@elisabeth> <20250923123213.61ddd9d5@elisabeth> <20250924104632.75b3f5a8@elisabeth> <20250924085621.GT1460@redhat.com> <20250924110909.43a16cfa@elisabeth> <20250924103131.GU1460@redhat.com> <20250924130553.673cc9c0@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: O4ZFvIBCyHH39rTs4dwaguSjuSBHzfYCtzE4Wb2nRAs_1758714530 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: Z6IWSSQN473V4LOW6FFNR4M3W2NOBLOL X-Message-ID-Hash: Z6IWSSQN473V4LOW6FFNR4M3W2NOBLOL 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: "Richard W.M. Jones" , Yumei Huang , 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 Wed, 24 Sep 2025 12:20:03 +0100 Daniel P. Berrang=C3=A9 wrote: > On Wed, Sep 24, 2025 at 01:05:53PM +0200, Stefano Brivio wrote: > > On Wed, 24 Sep 2025 11:31:31 +0100 > > "Richard W.M. Jones" wrote: > > =20 > > > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote: =20 > > > > And now that you say that, I just realised that it would be as simp= le > > > > as: > > > >=20 > > > > https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-= running-libguestfs-as-root > > > >=20 > > > > LIBGUESTFS_BACKEND=3Ddirect virt-edit... =20 > > >=20 > > > While that will indeed work, we're trying to discourage people from > > > doing that, since it removes the other good things that libvirt does, > > > such as setting up SELinux. =20 > >=20 > > Oh, I see. I guess it makes sense, with a number of caveats: > >=20 > > 1. libvirt's SELinux policy doesn't seem to be really maintainable / > > long-term sustainable to me, especially because it's still part of > > fedora-selinux =20 >=20 > Well it isn't ideal that Fedora policy is largely centralized, but > it has been maintained it since 2007, so claiming it is not long > term sustainable is just FUD. I'd rather call it observation. We're just piling up workarounds because merge requests are not really evaluated or accepted, for example https://github.com/fedora-selinux/selinux-policy/pull/1613. Your own comment to it: https://github.com/fedora-selinux/selinux-policy/pull/1613#issuecomment-1= 467759276 perfectly explains one of the biggest maintainability concerns I have, because not being able to use interfaces as designed leads to issues such as: https://github.com/fedora-selinux/selinux-policy/issues/2579 for which, again, I could propose a simple change, but I don't exactly have confidence that it will be considered. That leads in turn to more workarounds, say: https://passt.top/passt/commit/?id=3D87471731e6bb0b5df3a50277527caf3381b4= 5ee4 https://passt.top/passt/commit/?id=3D98d474c8950e9cc5715d5686614fb0f50437= 7303 I don't understand how the fact that it's been like that since 2007 would suggest a positive or negative correlation to maintainability. Things keeps breaking and I keep adding more workarounds, not fixes. You can go ahead and blame me for that, but I was talking about how *I* perceive maintainability. Again: > 1. libvirt's SELinux policy doesn't seem to be really maintainable / > long-term sustainable to me ^^ ...we probably have different concepts of it. That doesn't make it FUD. > > 2. it adds a rather artificial dependency on libvirt, so in the end > > you're running more things, and more complicated ones, even if it's > > not needed =20 >=20 > Libvirt provides a stable interface to interacting with QEMU > over decades. QEMU's own interface is only guaranteed stable > over 2 releases. As QEMU changes its interface and/or best > practice configuration approach, libvirt adapts to this so > every app doesn't have to repeat this work. It depends on the use case. For the use case at hand, we would be absolutely fine with things breaking every six months, or even more frequently. > > 3. the profile is still much looser than what a libguestfs specific > > profile could be, see for example the AppArmor policy I introduced > > at: > >=20 > > https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b= 1bcb8a6621d0b61907f9269a2506680684f > >=20 > > which, despite being rather loose, is still arguably much stricter > > than this beast (and related add-ons): > >=20 > > https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/appa= rmor/usr.sbin.libvirtd.in > >=20 > > and I think a strict subset of it, as well. =20 >=20 > This is the policy for the libvirt daemon, which is separate from the > policy that the QEMU guest runs under - the latter is constrained to > limit access to resources configured for the guest VM. >=20 > The libvirt daemon policy needs to be loose by default, since users > want libvirt to be able to access a wide range of files and resources. > This same need applies to guestfish - it needs to access arbitrarily > specified disk images, so would need a very loose policy. About disk images, of course, that's what I added for libguestfs: /** mrwlk and that's the same in libvirt's AppArmor policy. The set of permitted capabilities is very different, though, and libguestfs doesn't of course need all those helpers or, say, the ability to mount /dev, which, with AppArmor, can't be qualified / limited much further than that. > Only the > spawned QEMU could be confined strictly, and that would be equiv to > what is already done with libvirt's policy for QEMU. ...see links above? Those are not equivalent. --=20 Stefano