From: Eric Blake <eblake@redhat.com>
Date: Tue, 12 Jul 2011 22:47:01 +0000 (-0600)
Subject: util: honor anchored names when searching for executables
X-Git-Tag: v0.9.4-rc1~211
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=51fc56553f33d720d5d95900469a77f4ea9685b9;p=thirdparty%2Flibvirt.git

util: honor anchored names when searching for executables

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.

This tightens existing behavior, but most callers already pass
an absolute name or a name with no slashes, so it probably won't
be noticeable.

* src/util/util.c (virFindFileInPath): Anchored relative names do
not invoke a PATH search.
---

diff --git a/src/util/util.c b/src/util/util.c
index 62e0152c3e..08c805057a 100644
--- a/src/util/util.c
+++ b/src/util/util.c
@@ -578,7 +578,7 @@ int virFileResolveLink(const char *linkpath,
  */
 char *virFindFileInPath(const char *file)
 {
-    char *path;
+    char *path = NULL;
     char *pathiter;
     char *pathseg;
     char *fullpath = NULL;
@@ -596,6 +596,15 @@ 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, '/')) {
+        if (virFileIsExecutable(file))
+            ignore_value(virFileAbsPath(file, &path));
+        return path;
+    }
+
     /* copy PATH env so we can tweak it */
     path = getenv("PATH");