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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/