Hard code system path

There is little point reading the path from the environment.

First, it will be the path which systemd set for the environment in which
systemd started the corewatcher daemon.  That may or may not match the
system path.  And it is even more likely to not match the path set in
the environment in which a regular user has interactively started an app.

Second, by searching the path, we get false positive matches.  The crashdb
server has shown a variety of examples of crashes where a matching
app name was found in a developer's custom path.  We also have gotten
crashes reports where a developer was working on local dev/test of a
program whose name matched a binary's name from elsewhere in the path
(subsequent patches will deal more with this case).

Signed-off-by: Tim Pepper <timothy.c.pepper@linux.intel.com>

1 files changed, 2 insertions, 5 deletions

diff --git a/src/find_file.c b/src/find_file.c
index f520cac..e8bc93e 100644
--- a/src/find_file.c
+++ b/src/find_file.c
@@ -23,7 +23,8 @@
 
 char *find_apppath(char *fragment)
 {
-	char *path, *c1, *c2;
+	char *path = "/usr/bin"; /* system path */
+	char *c1, *c2;
 	char *filename = NULL;
 
 	fprintf(stderr, "+ Looking for %s\n", fragment);
@@ -38,8 +39,6 @@ char *find_apppath(char *fragment)
 		return filename;
 	}
 
-	path = strdup(getenv("PATH"));
-
 	c1 = path;
 	while (c1 && strlen(c1)>0) {
 		free(filename);
@@ -50,13 +49,11 @@ char *find_apppath(char *fragment)
 			return NULL;
 		if (!access(filename, X_OK)) {
 			printf("+ Found %s\n", filename);
-			free(path);
 			return filename;
 		}
 		c1 = c2;
 		if (c2) c1++;
 	}
-	free(path);
 	free(filename);
 	return NULL;
 }