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@xxxxxxxxxx>: > > > 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
Attachment:
signature.asc
Description: PGP signature
