[libvirt] [PATCH] 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. * 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"); -- 1.7.4.4
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 07/12/2011 08:51 PM, Daniel Veillard wrote:
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.
+ /* 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.
You can already run binaries outside of $PATH by giving an absolute name. All this does is actually avoid the PATH search on anchored relative names.
But virFindFileInPath() shouldn't be the place to implement such a security control, so ACK,
I realized that I missed two pieces - virFileAbsPath is attribute-warn-unused, and the file also has to be executable. I squashed this in, then pushed. diff --git i/src/util/util.c w/src/util/util.c index 1654cc2..08c8050 100644 --- i/src/util/util.c +++ w/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; @@ -600,7 +600,8 @@ char *virFindFileInPath(const char *file) * is no path search - it must exist in the current directory */ if (strchr(file, '/')) { - virFileAbsPath(file, &path); + if (virFileIsExecutable(file)) + ignore_value(virFileAbsPath(file, &path)); return path; } -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (2)
-
Daniel Veillard -
Eric Blake