From 5f610368cc4f1df01ac0da9a8eda96672757bbc9 Mon Sep 17 00:00:00 2001 From: Tim Pepper Date: Mon, 26 Nov 2012 13:59:26 -0800 Subject: [PATCH] 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 --- src/find_file.c | 7 ++----- 1 file 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; } -- 2.7.4