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.

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.

ErrProtectorName:
	Rename to ErrLoginProtectorName for clarity, and include the
	name and user.

ErrMissingProtectorName:
	Include the correct protector source.

ErrDuplicateName:
	Rename to ErrProtectorNameExists for clarity, and remove a level
	of wrapping by including the name directly.

ErrDuplicateUID:
	Rename to ErrLoginProtectorExists for clarity, and remove a
	level of wrapping by including the user directly.

Allow overriding the mountpoint where login protectors are stored by
setting the FSCRYPT_ROOT_MNT environmental variable.  The CLI tests need
this to avoid touching the real "/".

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.

Running "go vet -shadow ./..." finds all places where a variable might
be incorrectly or unnecessarily shadowed. This fixes some of them.

This user is used with policies to interface with the keryings and with
protectors to indicate which user's login passphrase should be used to
protectors of type pam_passphrase.

This commit changes all the internal import paths from `fscrypt/foo` to
`github.com/google/fscrypt/foo` so that it can be built once we release
externaly. The documentation in README.md is updated accordingly.

Also, the README has a note noting that we do not make any guarantees
about project stability before 1.0 (when it ships with Ubuntu).

Change-Id: I6ba86e442c74057c8a06ba32a42e17f94833e280

This commit changes the error handling for the actions package to use
the error handling library github.com/pkg/errors. This means replacing
"errors" with "github.com/pkg/errors", reworking some of the error
values, and wrapping some errors with additional context.

This commit also changes the Protector/Policy API, moving most of the
package functionality into Protector or Policy methods. These types are
now "locked" when they are queried from the filesystem, and Unlock()
must be used to get their corresponding keys. Note that only certain
operations will require unlocking the keys. Certain unnecessary
functions and methods are also removed.

This CL also fixes two bugs reported by Tyler Hicks in CreateConfigFile.
CPU time is used instead of wall time, and kiB is used instead of kB.

Change-Id: I88f45659e9fe4938d148843e3289e7b6d5b698d8

This commit makes the callbacks for getting keys easier to understand.
Functions which need keys now take a KeyFunc callback. This callback
contains a ProtectorInfo parameter (basically a read-only version of
metadata.ProtectorData) and a boolean which indicates if the call is
being retried. The documentation is also updated to say which functions
will retry the KeyFunc.

For selecting a protector, there is now an OptionFunc callback which
takes a slice of ProtectorOptions. A ProtectorOption is a ProtectorInfo
along with additional information about a linked filesystem (if
applicable).

This commit also adds in methods for getting the protector options for a
specific filesystem or policy. It also adds a function for getting the
policy descriptor for a specific path.

Change-Id: I41e0d94ffd44e7166b0c5cf1b5d18437960bdf90