fusermount: bail out on transient config read failure

If an attacker wishes to use the default configuration instead of the
system's actual configuration, they can attempt to trigger a failure in
read_conf(). This only permits increasing mount_max if it is lower than the
default, so it's not particularly interesting. Still, this should probably
be prevented robustly; bail out if funny stuff happens when we're trying to
read the config.

Note that the classic attack trick of opening so many files that the
system-wide limit is reached won't work here - because fusermount only
drops the fsuid, not the euid, the process is running with euid=0 and
CAP_SYS_ADMIN, so it bypasses the number-of-globally-open-files check in
get_empty_filp() (unless you're inside a user namespace).

1 files changed, 9 insertions, 0 deletions

diff --git a/util/fusermount.c b/util/fusermount.c
index 5175c01..012affb 100644
--- a/util/fusermount.c
+++ b/util/fusermount.c
@@ -566,10 +566,19 @@ static void read_conf(void)
 			fprintf(stderr, "%s: reading %s: missing newline at end of file\n", progname, FUSE_CONF);
 
 		}
+		if (ferror(fp)) {
+			fprintf(stderr, "%s: reading %s: read failed\n", progname, FUSE_CONF);
+			exit(1);
+		}
 		fclose(fp);
 	} else if (errno != ENOENT) {
+		bool fatal = (errno != EACCES && errno != ELOOP &&
+			      errno != ENAMETOOLONG && errno != ENOTDIR &&
+			      errno != EOVERFLOW);
 		fprintf(stderr, "%s: failed to open %s: %s\n",
 			progname, FUSE_CONF, strerror(errno));
+		if (fatal)
+			exit(1);
 	}
 }