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).
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