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).

0 files changed, 0 insertions, 0 deletions