Since commit 4c7c6631cc5a ("Set owner of login protectors to correct
user"), login protectors are made owned by the user when root creates
one on a user's behalf.  That's good, but the same isn't true of other
files that get created at the same time:

- The policy protecting the directory
- The protector link file, if the policy is on a different filesystem
- The recovery protector, if the policy is on a different filesystem
- The recovery instructions file

In preparation for setting all metadata files to mode 0600, start making
all these files owned by the user in this scenario as well.

A previous commit extended file ownership validation to policy and
protector files (by default -- there's an opt-out in /etc/fscrypt.conf).

However, that didn't apply to the parent directories:

	MOUNTPOINT
	MOUNTPOINT/.fscrypt
	MOUNTPOINT/.fscrypt/policies
	MOUNTPOINT/.fscrypt/protectors

The problem is that if the parent directories aren't trusted (owned by
another non-root user), then untrusted changes to their contents can be
made at any time, including the introduction of symlinks and so on.

While it's debatable how much of a problem this really is, given the
other validations that are done, it seems to be appropriate to validate
the parent directories too.

Therefore, this commit applies the same ownership validations to the
above four directories as are done on the metadata files themselves.

In addition, it is validated that none of these directories are symlinks
except for ".fscrypt" where this is explicitly supported.

The metadata validation checks introduced by the previous commits are
good, but to reduce the attack surface it would be much better to avoid
reading and parsing files owned by other users in the first place.

There are some possible use cases for users sharing fscrypt metadata
files, but I think that for the vast majority of users it is unneeded
and just opens up attack surface.  Thus, make fscrypt (and pam_fscrypt)
not process policies or protectors owned by other users by default.
Specifically,

   * If fscrypt or pam_fscrypt is running as a non-root user, only
     policies and protectors owned by the user or by root can be used.

   * If fscrypt is running as root, any policy or protector can be used.
     (This is to match user expectations -- starting a sudo session
     should gain rights, not remove rights.)

   * If pam_fscrypt is running as root, only policies and protectors
     owned by root can be used.  Note that this only applies when the
     root user themselves has an fscrypt login protector, which is rare.

Add an option 'allow_cross_user_metadata' to /etc/fscrypt.conf which
allows restoring the old behavior for anyone who really needs it.

World-writable directories are not appropriate for some systems, so
offer a choice of single-user-writable and world-writable modes, with
single-user-writable being the default.  Add a new documentation section
to help users decide which one to use.

Make remove-protector-from-policy work even if the protector cannot be
loaded (for example, due to having been deleted already).

Fixes https://github.com/google/fscrypt/issues/258
Fixes https://github.com/google/fscrypt/issues/272

This fixes a test failure in the case where test.conf gets left over.

As per the feedback at https://github.com/google/fscrypt/issues/115
where users didn't understand that the recovery passphrase is important,
restore the original behavior where recovery passphrase generation
happens automatically without a prompt.  This applies to the case where
'fscrypt encrypt' is using a login protector on a non-root filesystem.

However, leave the --no-recovery option so that the recovery passphrase
can still be disabled if the user really wants to.  Also, clarify the
information provided about the recovery passphrase.

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

Running `crypto.PassphraseHash` in a loop allocates a lot of memory.
Golang is not always prudent about collecting the garbage from previous
runs, resulting in a OOM error on memory-pressured systems.

With a `maxMemoryBytes` of 128 MiB, this change reduces the maximum
resident memory for `fscrypt setup` to 141 MiB (was perviously 405 MiB)

Signed-off-by: Joe Richey <joerichey@google.com>

On systems with high memory pressure, using half of the entire RAM for
hashing can result in fscrypt getting OOM killed.

Signed-off-by: Joe Richey <joerichey@google.com>

Introduce filesystem.ErrEncryptionNotEnabled and
filesystem.ErrEncryptionNotSupported which include the Mount as context,
and translate the corresponding metadata/ errors into them.  Then make
these errors show much better suggestions.

Also replace lots of other filesystem/ errors with either custom types
or with unnamed one-off errors that include more context.  Fix backwards
wrapping in lots of cases.

Finally, don't include the mountpoint in places where it's not useful,
like OS-level errors that already include the path.