This allows us to fix the bug where Parallelism is inadvertantly
truncated to 8 bits in a backwards compatible way.

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

Follow up to #362

Protojson randomly inserts whitespace to indicate that the output is
unstable, breaking out tests. To fix this, compact the output before
comparison.

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

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

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

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.

There's no real need to allow users to choose the key description prefix
(a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4"
and "f2fs" for compatibility with all kernels both old and new, and on
other filesystems we can just use "fscrypt".  So, let's do that.

Since this removes the point of the "--legacy" option to 'fscrypt setup'
and the "compatibility" field in /etc/fscrypt.conf, remove those too.

Specifically, we start ignoring the "compatibility" in existing config
files and not writing it to new ones.  The corresponding protobuf field
number and name are reserved.  We stop accepting the "--legacy" option
at all, although since it was default true and there was no real reason
for anyone to change it to false, probably no one will notice.  If
anyone does, they should just stop specifying the option.

Note that this change only affects user keyrings and thus only affects
v1 encryption policies, which are deprecated in favor of v2 anyway.

Linux v5.4 and later supports v2 encryption policies.  These have
several advantages over v1 encryption policies:

- Their encryption keys can be added/removed to/from the filesystem by
  non-root users, thus gaining the benefits of the filesystem keyring
  while also retaining support for non-root use.

- They use a more standard, secure, and flexible key derivation
  function.  Because of this, some future kernel-level fscrypt features
  will be implemented for v2 policies only.

- They prevent a denial-of-service attack where a user could associate
  the wrong key with another user's encrypted files.

Prepare the fscrypt tool to support v2 encryption policies by:

- Adding a policy_version field to the EncryptionOptions, i.e. to the
  config file and to the policy metadata files.

- Using the kernel-specified algorithm to compute the key descriptor for
  v2 policies.

- Handling setting and getting v2 policies.

Actually adding/removing the keys for v2 policies to/from the kernel is
left for the next patch.

Linux v5.4 and later allows fscrypt keys to be added/removed directly
to/from the filesystem via the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY.  Among other benefits, these fix the key
visibility problems that many users have been running into, where system
services and containers can't access encrypted files.

Allow the user to opt-in to using these new ioctls for their existing
encrypted directories by setting in their /etc/fscrypt.conf:

	"use_fs_keyring_for_v1_policies": true

Note that it can't really be on by default, since for v1 policies the
ioctls require root, whereas user keyrings don't.  I.e., setting this to
true means that users will need to use 'sudo fscrypt unlock', not
'fscrypt unlock'.  v2 policies won't have this restriction.

As new encryption modes are being added to the kernel that use 128 bit
keys (see https://patchwork.kernel.org/patch/9741913), we will need the
encryption modes to be more descriptive.

This change breaks backwards compatibility for the protobuf, but that's
fine because we have not released yet.

Change-Id: Ifb58d3d5a42db491f1e5393c12f3d260d9a091de

This commit adds in IsValid() checks for the metadata structures that
let us enforce stronger invariants than those imposed by the protobuf
package. The main uses of this will be to check that metadata is valid
before writing it to the filesystem, and to check that the filesystem
contains valid metadata before returning it to the user. These functions
also will log the exact reason if the validity checks fail.

To have these checks in the metadata package, all of the various
constants have been moved to a single metadata/constants.go file. The
uses of these constants were changed accordingly.

Finally, this commit standardizes our use of errors so that they always
begin with an appropriate prefix.

Change-Id: I99008e2ee803ebe5f6236eb8d83fc83efcd22718