This prevents panics on 256-core systems, and has a 300-core system use
255 CPUs (the max) rather than 44 CPUs (300 casted to a uint8).

Signed-off-by: Joe Richey <joerichey@google.com>
[ebiggers: also set TruncationFixed at the end of getHashingCosts()]
Signed-off-by: Eric Biggers <ebiggers@google.com>

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.

github.com/golang/protobuf/proto has been deprecated in favor of
google.golang.org/protobuf/proto, so migrate to the non-deprecated one.

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.