On Fri, Nov 20, 2020 at 01:19:33AM +0100, Pavel Hrdina wrote:
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(a)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.
Some of them look like they are handled already, but of course we need to make
sure all of them work. Maybe just prepending/appending /usr/libexec/ to the
list of directories in virFileFindInPath() or a similar method would do, I don't
know.
I'm glad we're on the same canoe =)
Pavel