| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
I'm not sure how this passed the GitHub checks.
|
|
filesystem: store mountpoint in link files as a fallback
|
|
|
|
Currently, linked protectors use filesystem link files of the form
"UUID=<uuid>". These links get broken if the filesystem's UUID changes,
e.g. due to the filesystem being re-created even if the ".fscrypt"
directory is backed up and restored.
To prevent links from being broken (in most cases), start storing the
mountpoint path in the link files too, in the form
"UUID=<uuid>\nPATH=<path>\n". When following a link, try the UUID
first, and if it doesn't work try the PATH. While it's possible that
the path changed too, for login protectors (the usual use case of linked
protectors) this won't be an issue as the path will always be "/".
An alternative solution would be to fall back to scanning all
filesystems for the needed protector descriptor. I decided not to do
that, since relying on a global scan doesn't seem to be a good design.
It wouldn't scale to large numbers of filesystems, it could cross
security boundaries, and it would make it possible for adding a new
filesystem to break fscrypt on existing filesystems. And if a global
scan was an acceptable way to find protectors during normal use, then
there would be no need for link files in the first place.
Note: this change is backwards compatible (i.e., fscrypt will continue
to recognize old link files) but not forwards-compatible (i.e., previous
versions of fscrypt won't recognize new link files).
Fixes https://github.com/google/fscrypt/issues/311
|
|
When the root user creates a login protector for a non-root user, make
sure to chown() the protector file to make it owned by the user.
Without this, the protector cannot be updated by the user, which causes
it to get out of sync if the user changes their login passphrase.
Fixes https://github.com/google/fscrypt/issues/319
|
|
As per the feedback at https://github.com/google/fscrypt/issues/115
where users didn't understand that the recovery passphrase is important,
restore the original behavior where recovery passphrase generation
happens automatically without a prompt. This applies to the case where
'fscrypt encrypt' is using a login protector on a non-root filesystem.
However, leave the --no-recovery option so that the recovery passphrase
can still be disabled if the user really wants to. Also, clarify the
information provided about the recovery passphrase.
Update https://github.com/google/fscrypt/issues/115
|
|
Test encrypting a directory using a login (pam_passphrase) protector.
|
