From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=WQphRnRp; 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 ESMTP id 3FD615A004C for ; Mon, 26 Aug 2024 10:57:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1724662639; 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=JirtsPg0QVHo6Ds+X64gG89BrY0c+j9ZQKrz8MdF3Jw=; b=WQphRnRp3k46AO89L+HliCwG4dw5N7hl55gdUaZCzKn7bO8w6zLodIaVhsPwD1gfjDrsKo VsSs9mRN4lAycJh7HVIer37RSYD3yfWD9yDy+RJFjpUZN2bZ8xX8yfj0fUXCbx/ma5+T/b IZ2bviVoFc6Jy7Y3gt8rbOQnIaXxD1g= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-14-6ApwzkNlMW-QEJnMX3KIlg-1; Mon, 26 Aug 2024 04:57:17 -0400 X-MC-Unique: 6ApwzkNlMW-QEJnMX3KIlg-1 Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-1ff24acb60dso38162655ad.0 for ; Mon, 26 Aug 2024 01:57:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724662636; x=1725267436; 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=JirtsPg0QVHo6Ds+X64gG89BrY0c+j9ZQKrz8MdF3Jw=; b=t1hb2xs11bNZz5o1O11XIfbGyoWua2T0FiFzYXtQJXTxVH88Oa51TwaJo5RxtwlkgV PSvRJv8bHDjdGCFVtFxsIhdJTiS6OzZBqfLgvZjVwX6o7NAhjpMKNe/bVIOwR7H0Cmpg xKCS+CzRsvkqJm/KLUPCry8zFuezD4Ip2ry+FQX5gloLZ8B3fuzXK2vPuJzU5Mguar8N 88n4D37fIvzILuGjYKpMq/DdhDk4DuAbwil7sEhc9TkuSTHXItKvSX0DDAwkj0tugajZ eDaKMU9B/kpQ2UfIpGo4R8dKEL+lxHBLntgQcA0WNYbs+U8lVe0WV3MbBJ6XuMIA+qsE kHKA== X-Gm-Message-State: AOJu0YxcNC9b0pUSqOjUwjdBnLit5qgKzmn+q+gqRWVa0cs9GkaghqFi K5t0fe41aUm8sWHeu22EoInzkkrMO/Ohchh1HEawBQs/RY9O96i1UQsjf3mkZrSrjSavvD5KpmG dIR3PSXBNb2zvkMfuclx6KRAKgBB/pSZAJzizCaSPNyy+LwjQH5/+G0R/Dg== X-Received: by 2002:a17:902:e88d:b0:1ff:43a8:22f2 with SMTP id d9443c01a7336-2037fe188b8mr199120855ad.24.1724662635712; Mon, 26 Aug 2024 01:57:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEd7a1E9QGCpwCpGtoa8+dsVyFzvChy6lXZ03g4dlphuCPJioE+pQSUhQ0BQl+SJblPgQ7m/w== X-Received: by 2002:a17:902:e88d:b0:1ff:43a8:22f2 with SMTP id d9443c01a7336-2037fe188b8mr199120665ad.24.1724662635218; Mon, 26 Aug 2024 01:57:15 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20385be1c04sm63422565ad.267.2024.08.26.01.57.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 01:57:14 -0700 (PDT) Date: Mon, 26 Aug 2024 10:57:12 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] Remove incorrect special handling of /usr/libexec Message-ID: <20240826105712.3f4ce3a8@elisabeth> In-Reply-To: References: <20240826063901.590640-1-david@gibson.dropbear.id.au> <20240826095547.43a050fd@elisabeth> <20240826103723.60e04eb6@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: BICUFX2RY4JLGYECAHHGSFZNWYQFKDIK X-Message-ID-Hash: BICUFX2RY4JLGYECAHHGSFZNWYQFKDIK 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 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 Mon, 26 Aug 2024 18:47:27 +1000 David Gibson wrote: > On Mon, Aug 26, 2024 at 10:37:23AM +0200, Stefano Brivio wrote: > > On Mon, 26 Aug 2024 18:20:35 +1000 > > David Gibson wrote: > > > > > On Mon, Aug 26, 2024 at 09:55:47AM +0200, Stefano Brivio wrote: > > > > On Mon, 26 Aug 2024 16:39:01 +1000 > > > > David Gibson wrote: > > > > > > > > > The statement in the comment about /usr/libexec being only for running on > > > > > other hosts simply isn't true, neither in practice nor according to the > > > > > FHS spec[0]. > > > > > > > > I don't remember where I took that meaning of /usr/libexec from, I > > > > guess it's from some outdated packaging guidelines (Fedora? Kata > > > > Containers?). Sure, it makes sense to fix that. > > > > > > > > > Furthermore this logic didn't even handle it correctly, since > > > > > it would only handle binaries _directly_ in /usr/libexec, not those in > > > > > (explicitly FHS permitted) subdirectories under /usr/libexec. > > > > > > > > So, this change breaks the two cases I needed to cover with this, which > > > > are /usr/libexec/kata-agent in general, and /usr/libexec/qemu-kvm on > > > > RHEL 9. > > > > > > Huh.. why? > > > > Because they're not in PATH on the guest, so we can't execute them. > > But.. they wouldn't have been in the PATH on the host either, so > whatever front end binary is using them must have found them by some > other means. If you actually use the front-end binary, sure. The issue is the interpretation of "intended" in the FHS description: /usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. ...not intended on a specific distribution? Or due to their nature? > > As an alternative, we can unconditionally add /usr/libexec to it using > > $FIXUP. I added the lines moving stuff to /usr/bin before I implemented > > the $FIXUP mechanism, and I needed to run kata-agent as init. > > > > But now that $FIXUP is available, that's probably less invasive. > > > > > > What does it fix? > > > > > > I don't have a concrete case, but it would break anything where we're > > > including this support binary, but the "front end" binary looks for it > > > explicitly in /usr/libexec. Which I'd kind of expect to be most > > > support binary cases, since by design /usr/libexec won't generally be > > > in the PATH. > > > > I see. Well, given the limited time I can spend on maintaining mbuto, > > I'd really prefer to just fix concrete issues, but this looks obvious > > enough -- as long as we have another way to keep qemu-kvm usable in the > > guest. > > Ah... I guess for qemu-kvm we're intentionally taking what's a support > binary on the host and using it as a primary binary on the guest. Right, same for kata-agent. > That's different from the sshd-session case, where it's a support > binary in both environments. > > I'd favour leaving the path of the binary itself alone and explicitly > adding a link from /usr/bin for the qemu-kvm case. We could add a link from /usr/bin for all the paths we find in /usr/libexec, then, to keep it more general. But is it really worth the effort compared to just adding /usr/libexec to $PATH on the guest? -- Stefano