Ensure that when an encryption policy is reverted (e.g. due to
encryptPath() failing after the policy was created), we also delete any
new protector links that were created for the policy, as this is not
handled by the logic that reverts new protectors.

When adding a protector to a policy, don't unconditionally overwrite the
protector link, because it may already exist.  Instead, if it already
exists and points to the mount, just use it.  If it already exists and
points to the wrong place, return an error.

Also add a bool to the return value of AddLinkedProtector() so that
callers can check whether the link was newly created or not.

Ensure that a failed AddRecoveryPassphrase() doesn't leave around an
unneeded protector file.

If the login protector was just created by the same 'fscrypt encrypt'
command, then policy.Context.Config.Source will be pam_passphrase.  This
needs to be overridden to custom_passphrase when creating the protector
for the recovery passphrase.

This fixes the following error:

    fscrypt encrypt: login protectors do not need a name

Resolves https://github.com/google/fscrypt/issues/187
Update https://github.com/google/fscrypt/issues/186

If a user re-installs their system (or otherwise loses the /.fscrypt
directory on the root filesystem) they also lose access to any login
passphrase-protected directories on other filesystems, unless additional
protectors were manually added.  This can be unexpected, as it may be
expected that the old login passphrase would still work.

We can't really fix this by storing a login protector on every
filesystem because:

- If a user were to have N login protectors, it would take them N times
  longer to log in, as every login protector would need to be unlocked.

- If a user were to change their login passphrase while any external
  volumes were unmounted, login protectors would get out of sync.

- It's preferable that an external volume isn't unlockable by itself
  using only a login passphrase, as login passphrases are often weak.

Instead, generate a recovery passphrase when creating a login
passphrase-protected directory on a non-root filesystem.

The recovery passphrase is added as a custom_passphrase protector, thus
giving the policy two protectors: one pam_passphrase and one
custom_passphrase.  Then this passphrase is written to a file in the new
encrypted directory.  Writing the passphrase to a file here is okay
since it's encrypted, but it's obviously useless by itself; it's up to
the user to store this passphrase somewhere else if they need it.

Use a recovery passphrase instead of a "recovery code" that encodes the
policy key directly because a passphrase is more user-friendly: it can
safely be made much shorter than a key, and it works just like any other
fscrypt protector.  Also, it's not as critical to allow recovery when
the .fscrypt directory on the *same* filesystem is deleted.

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

Allow root to provide the --all-users option to 'fscrypt lock' to force
an encryption key to be removed from the filesystem (i.e., force an
encrypted directory to be locked), even if other users have added it.

To implement this option, we just need to use the
FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl rather than
FS_IOC_REMOVE_ENCRYPTION_KEY.

In theory this option could be implemented for the user keyrings case
too, but it would be difficult and the user keyrings are being
deprecated for fscrypt, so don't bother.

Implement adding/removing v2 encryption policy keys to/from the kernel.
The kernel requires that the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY be used for this.  Root is not required.

However, non-root support brings an extra complication: the kernel keeps
track of which users have called FS_IOC_ADD_ENCRYPTION_KEY for the same
key.  FS_IOC_REMOVE_ENCRYPTION_KEY only works as one of these users, and
it only removes the calling user's claim to the key; the key is only
truly removed when the last claim is removed.

Implement the following behavior:

- 'fscrypt unlock' and pam_fscrypt add the key for the user, even if
  other user(s) have it added already.  This behavior is needed so that
  another user can't remove the key out from under the user.

- 'fscrypt lock' and pam_fscrypt remove the key for the user.  However,
  if the key wasn't truly removed because other users still have it
  added, 'fscrypt lock' prints a warning.

- 'fscrypt status' shows whether the directory is unlocked for anyone.

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.

FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY require root
for v1 policy keys, so update the PAM module to re-acquire root
privileges while provisioning/deprovisioning policies that need this.

Also, only set up the user keyring if it will actually be used.

Add support for 'fscrypt lock'.  This command "locks" a directory,
undoing 'fscrypt unlock'.

When the filesystem keyring is used, 'fscrypt lock' also detects when a
directory wasn't fully locked due to some files still being in-use.  It
can then be run again later to try to finish locking the files.