This has to be since the mounts are reloaded
each time a mount is added. In case of two
mounts mounting at the same time there will
be a race condition for applying policy.

Signed-off-by: NymanRobin <robin.nyman@est.tech>

Probably resolves https://github.com/google/fscrypt/issues/382

Since Go 1.16 (which recently became the minimum supported Go version
for this project), the package io/ioutil is deprecated in favor of
equivalent functionality in the io and os packages.  staticcheck warns
about this.  Address all the warnings by switching to the non-deprecated
replacement functions.

Following the example of /proc/self/mountinfo, replace the space,
newline, tab, and backslash characters with octal escape sequences so
that the output can be parsed unambiguously.

This is needed to allow creating protector links to btrfs filesystems.

Update https://github.com/google/fscrypt/issues/339

Add back the mountsByPath map, which indexes all Mounts by mountpoint.
This is needed again.

To avoid confusion, also rename two local variables named mountsByPath.

mountsByPath won't contain nil entries, so also make AllFilesystems()
use it instead of mountsByDevice.  This shouldn't change its behavior.

Update https://github.com/google/fscrypt/issues/339

Currently, linked protectors use filesystem link files of the form
"UUID=<uuid>".  These links get broken if the filesystem's UUID changes,
e.g. due to the filesystem being re-created even if the ".fscrypt"
directory is backed up and restored.

To prevent links from being broken (in most cases), start storing the
mountpoint path in the link files too, in the form
"UUID=<uuid>\nPATH=<path>\n".  When following a link, try the UUID
first, and if it doesn't work try the PATH.  While it's possible that
the path changed too, for login protectors (the usual use case of linked
protectors) this won't be an issue as the path will always be "/".

An alternative solution would be to fall back to scanning all
filesystems for the needed protector descriptor.  I decided not to do
that, since relying on a global scan doesn't seem to be a good design.
It wouldn't scale to large numbers of filesystems, it could cross
security boundaries, and it would make it possible for adding a new
filesystem to break fscrypt on existing filesystems.  And if a global
scan was an acceptable way to find protectors during normal use, then
there would be no need for link files in the first place.

Note: this change is backwards compatible (i.e., fscrypt will continue
to recognize old link files) but not forwards-compatible (i.e., previous
versions of fscrypt won't recognize new link files).

Fixes https://github.com/google/fscrypt/issues/311

Update the /proc/self/mountinfo parsing code to allow selecting a Mount
with Subtree != "/", i.e. a Mount not of the full filesystem.  This is
needed to allow fscrypt to work in containers, where the root of the
filesystem may not be mounted.

See findMainMount() for details about the algorithm used.

Resolves https://github.com/google/fscrypt/issues/211

To make manually editing linked protectors slightly more user-friendly,
automatically strip any leading or trailing whitespace.  E.g. treat
"UUID=3a6d9a76-47f0-4f13-81bf-3332fbe984fb\n" the same as
"UUID=3a6d9a76-47f0-4f13-81bf-3332fbe984fb".

Update https://github.com/google/fscrypt/issues/115

Add a version of loadMountInfo() that takes an io.Reader parameter to
allow injecting a custom mountinfo file, then add some unit tests.