ErrKeyLock:
	Rename to ErrMlockUlimit for clarity.

ErrGetrandomFail:
ErrKeyAlloc:
ErrKeyFree:
ErrNegativeLength:
	Replace these with one-off unnamed errors because these were all
	returned in only one place and were never checked for.  Also
	these were all either wrapped backwards or discarded an
	underlying error, so fix that too.

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

These were found by a combination of manual review and a custom script
that checks for common errors.

Also removed an outdated sentence from the comment for setupBefore().

This commit changes the error handing for the crypto, filesystem,
metadata, pam, and util packages to use the error handling library
github.com/pkg/errors. This means elimination of the FSError type, an
increased use of wrapping errors (as opposed to logging), switching
on the Cause() of an error (as opposed to its value), and improving our
integration tests involving TEST_FILESYSTEM_ROOT.

This commit also fixes a few bugs with the keyring code to ensure that
our {Find|Remove|Insert}PolicyKey functions are always operating on the
same keyring. The check for filesystem support has been moved from the
filesystem package to the metadata package. Finally, the API for the
filesystem package has been slightly modified:
	* filesystem.AllFilesystems() now returns all the filesystems in
	  sorted order
	* certain path methods are now public

O_SYNC is also removed for writing the metadata. We don't get that much
from syncing the metadata, as the actual file data could also be
corrupted by and IO error. The sync operation is also occasionally very
slow (~3 seconds) and can be unfriendly to battery life.

Change-Id: I392c2655141714b16dfdbc84ac09780072be2cf0

This changes the crypto package so it now builds in light of the changes
to the util and metadata package. This commit also improves the error
handling, adds tests, and makes it so recovery keys now correspond to
Policy keys (as they are used to recover a directory in the absence of
any metadata).

The only feature addition here is the ability to compute descriptors.
For backwards compatibility, we keep the same descriptor algorithm used
before (double SHA512).

Change-Id: Ia2b53c6e85ce65c57595e6823d3c4c92219bc8dc

This commit adds in RandReader, a cryptographically secure io.Reader
that will fail when the os has insufficient randomness. This is done
using the getrandom() syscall in non-blocking mode.
  see: http://man7.org/linux/man-pages/man2/getrandom.2.html
Any kernel new enough to have filesystem encryption will also have this
syscall.

This RandReader is preferable to the one provided by the standard
library in crypto/rand. See the bugs:
	https://github.com/golang/go/issues/11833
	https://github.com/golang/go/issues/19274
This will be removed when go updates the crypto/rand implementation.

Change-Id: Icccaf07bc6011b95cd31a5c268e7486807dcffe2