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 <passt-dev@passt.top>; 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 <passt-dev@passt.top>; 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 <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH] Remove incorrect special handling of /usr/libexec
Message-ID: <20240826105712.3f4ce3a8@elisabeth>
In-Reply-To: <ZsxBHzoPgoIyslcL@zatzit.fritz.box>
References: <20240826063901.590640-1-david@gibson.dropbear.id.au>
	<20240826095547.43a050fd@elisabeth>
	<Zsw600Zy2qZ95WI6@zatzit.fritz.box>
	<20240826103723.60e04eb6@elisabeth>
	<ZsxBHzoPgoIyslcL@zatzit.fritz.box>
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 <passt-dev.passt.top>
Archived-At: <https://archives.passt.top/passt-dev/20240826105712.3f4ce3a8@elisabeth/>
Archived-At: <https://passt.top/hyperkitty/list/passt-dev@passt.top/message/BICUFX2RY4JLGYECAHHGSFZNWYQFKDIK/>
List-Archive: <https://archives.passt.top/passt-dev/>
List-Archive: <https://passt.top/hyperkitty/list/passt-dev@passt.top/>
List-Help: <mailto:passt-dev-request@passt.top?subject=help>
List-Owner: <mailto:passt-dev-owner@passt.top>
List-Post: <mailto:passt-dev@passt.top>
List-Subscribe: <mailto:passt-dev-join@passt.top>
List-Unsubscribe: <mailto:passt-dev-leave@passt.top>

On Mon, 26 Aug 2024 18:47:27 +1000
David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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