Do not pass a path as the format string argument to errors.Wrapf(), as
this causes it to be misinterpreted as a format string, causing an
unexpected message if the path contains something like '%s'.  Instead
use errors.Wrap().  This was diagnosed by Go 1.24.

Fixes https://github.com/google/fscrypt/issues/422

Document the logic described in makeRawKey.

Since opening an encrypted regular file that is locked fails with
ENOKEY, getting the encryption policy of such a file is not possible.
As a result, 'fscrypt status' and 'fscrypt lock' fail on such files.
Provide a better error message that tries to explain what is going on.

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

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.

The latest version of 'staticcheck' warns about these.

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.