regression in meson build, AC_PATH_PROG lost

[Pavel Hrdina]

On Thu, Nov 19, 2020 at 11:38:28PM +0100, Martin Kletzander wrote:
> On Thu, Nov 19, 2020 at 10:31:00PM +0100, Olaf Hering wrote:
> > Am Thu, 19 Nov 2020 22:15:27 +0100
> > schrieb Martin Kletzander <mkletzan at redhat.com>:
> > 
> > > Libvirt needs to be able to handle that missing binary at runtime anyway
> > 
> > It also needs to handle an existing binary. Just how is it supposed to handle it?
> > 
> 
> Um... run it?
> 
> > Right now with meson it is either a full path, or just the name in case it was missing at build time (I have not checked if the launcher actually consults $PATH).
> > 
> 
> Right now, IMHO, all meson checks for binaries that are not needed at build time
> should be removed.  During runtime we can just use the name of the binary.  I
> don't know whether it used to be the case that it was thought that there might
> be security issues with supplying different binary in a directory in $PATH, but
> frankly, if you have (different-)user-writable directory in $PATH or non-root
> access to modifying system-wide $PATH then you have bigger problems to deal
> with.  Even though I do not have anything to back this claim I think that
> might've been the original reason.

That was my take on the original reasoning as well. I completely agree
here with Martin and vote for removing these runtime binary checks from
meson completely. There would be also the benefit for testing purposes
that you can simply change the path to use your own compiled binary
without changing anything in libvirt.

I guess we have to have some exceptions like for the QEMU helpers that
usually lives in /usr/libexec which is not intentionally part of $PATH.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20201120/19e602d5/attachment-0001.sig>