[libvirt] [PATCH] util: honor anchored names when searching for executables

[Daniel Veillard]

On Tue, Jul 12, 2011 at 04:51:51PM -0600, Eric Blake wrote:
> I got bit in a debugging session on an uninstalled libvirtd; the
> code tried to call out to the installed $LIBEXECDIR/libvirt_iohelper
> instead of my just-built version.  So I set a breakpoint and altered
> the binary name to be "./src/libvirt_iohelper", and it still failed
> because I don't have "." on my PATH.
> 
> According to POSIX, execvp only searches PATH if the name does
> not contain a slash.  Since we are trying to mimic that behavior,
> an anchored name should be relative to the current working dir.
> 
> * src/util/util.c (virFindFileInPath): Anchored relative names do
> not invoke a PATH search.
> ---
>  src/util/util.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/src/util/util.c b/src/util/util.c
> index 1441c51..20ccfa7 100644
> --- a/src/util/util.c
> +++ b/src/util/util.c
> @@ -596,6 +596,14 @@ char *virFindFileInPath(const char *file)
>              return NULL;
>      }
> 
> +    /* If we are passed an anchored path (containing a /), then there
> +     * is no path search - it must exist in the current directory
> +     */
> +    if (strchr(file, '/')) {
> +        virFileAbsPath(file, &path);
> +        return path;
> +    }
> +
>      /* copy PATH env so we can tweak it */
>      path = getenv("PATH");

That sounds right. The only issue is that the slight change of semantic
may suddenly allow to run binaries outside of $PATH which may be a
security concern. But virFindFileInPath() shouldn't be the place to
implement such a security control, so ACK,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/