aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-01-19filesystem: add back the mountsByPath mapEric Biggers
Add back the mountsByPath map, which indexes all Mounts by mountpoint. This is needed again. To avoid confusion, also rename two local variables named mountsByPath. mountsByPath won't contain nil entries, so also make AllFilesystems() use it instead of mountsByDevice. This shouldn't change its behavior. Update https://github.com/google/fscrypt/issues/339
2022-01-19Merge pull request #341 from google/fix-testEric Biggers
cli-tests: fix broken test
2022-01-19cli-tests: fix broken testEric Biggers
I'm not sure how this passed the GitHub checks.
2022-01-18Merge pull request #337 from google/broken-linksEric Biggers
filesystem: store mountpoint in link files as a fallback
2022-01-18Merge pull request #338 from google/remove-protector-from-policyEric Biggers
cmd/fscrypt: don't load protector in remove-protector-from-policy
2021-12-23cmd/fscrypt: don't load protector in remove-protector-from-policyEric Biggers
Make remove-protector-from-policy work even if the protector cannot be loaded (for example, due to having been deleted already). Fixes https://github.com/google/fscrypt/issues/258 Fixes https://github.com/google/fscrypt/issues/272
2021-12-23cli-tests: add helper functions to get protector descriptorsEric Biggers
2021-12-22filesystem: store mountpoint in link files as a fallbackEric Biggers
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
2021-12-22Merge pull request #336 from google/test-fixEric Biggers
context_text: remove pre-existing test.conf
2021-12-22context_text: remove pre-existing test.confEric Biggers
This fixes a test failure in the case where test.conf gets left over.
2021-12-21Merge pull request #335 from google/fix-typosEric Biggers
Fix a few typos
2021-12-21Fix a few typosEric Biggers
2021-12-21Merge pull request #334 from ebiggers/warn-on-chauthtok-failEric Biggers
pam_fscrypt: warn user if OLDAUTHTOK not given in chauthtok
2021-12-21pam_fscrypt: warn user if OLDAUTHTOK not given in chauthtokEric Biggers
If someone runs 'passwd USER' as root, the user is assigned a new login passphrase without their fscrypt login protector being updated. Detect this case and show a warning message using pam_info(). Fixes https://github.com/google/fscrypt/issues/273
2021-12-21Merge pull request #333 from ebiggers/doc-encryption-solutionsEric Biggers
README: elaborate on alternatives and threat model
2021-12-21README: elaborate on alternatives and threat modelEric Biggers
Fixes https://github.com/google/fscrypt/issues/318
2021-12-21README: write "Linux native filesystem encryption"Eric Biggers
"Linux filesystem encryption" sounds too vague. Write "Linux native filesystem encryption" instead.
2021-12-20Merge pull request #332 from ebiggers/skip-irrelevant-filesystemsEric Biggers
filesystem: avoid accessing irrelevant filesystems
2021-12-20filesystem: avoid accessing irrelevant filesystemsEric Biggers
Forbid 'fscrypt setup' on filesystems that aren't expected to support encryption (other than the root filesystem), and skip looking for fscrypt metadata directories on such filesystems. This has two benefits. First, it avoids the printing of annoying warnings like: pam_fscrypt[75038]: stat /run/user/0/.fscrypt: permission denied pam_fscrypt[75038]: stat /run/user/0/.fscrypt/policies: permission denied pam_fscrypt[75038]: stat /run/user/0/.fscrypt/protectors: permission denied pam_fscrypt[75038]: stat /sys/firmware/efi/efivars/.fscrypt: invalid argument pam_fscrypt[75038]: stat /sys/firmware/efi/efivars/.fscrypt/policies: invalid argument pam_fscrypt[75038]: stat /sys/firmware/efi/efivars/.fscrypt/protectors: invalid argument pam_fscrypt[75038]: stat /sys/fs/pstore/.fscrypt: permission denied pam_fscrypt[75038]: stat /sys/fs/pstore/.fscrypt/policies: permission denied pam_fscrypt[75038]: stat /sys/fs/pstore/.fscrypt/protectors: permission denied Second, it avoids long delays or side effects on some filesystems. To do this, introduce an allowlist of filesystem types that fscrypt will recognize. I wanted to avoid doing this, since this list will need to be updated in the future, but I don't see a better solution.
2021-12-20Merge pull request #331 from ebiggers/login-protector-permsEric Biggers
Set owner of login protectors to correct user
2021-12-20Merge pull request #329 from ebiggers/doc-ssh-issueEric Biggers
README: document issue with ssh ChallengeResponseAuthentication
2021-12-20Merge pull request #330 from google/avoid-warningEric Biggers
pam: avoid compiler warning in copyIntoSecret()
2021-12-19Set owner of login protectors to correct userEric Biggers
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
2021-12-19pam: avoid compiler warning in copyIntoSecret()Eric Biggers
gcc 11 enabled -Wmaybe-uninitialized by default. It causes a false-positive warning in copyIntoSecret() because gcc doesn't understand that mlock() is special and doesn't read from the memory. Just initialize the memory to avoid this warning.
2021-12-19README: document issue with ssh ChallengeResponseAuthenticationEric Biggers
Update https://github.com/google/fscrypt/issues/321 Update https://github.com/google/fscrypt/issues/324
2021-11-29Merge pull request #326 from dimitry-ishenko/stdinEric Biggers
cmd/fscrypt: read key from stdin in non-interactive shell
2021-11-29cmd/fscrypt: read key from stdinDimitry Ishenko
Fixes #123
2021-10-18Release version v0.3.1v0.3.1Eric Biggers
2021-10-05Adjust recovery passphrase generationEric Biggers
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
2021-09-22Merge pull request #317 from ebiggers/readme-symlink-bugJoseph Richey
README: mention LTS kernel versions with symlink bug fix
2021-09-22README: mention LTS kernel versions with symlink bug fixEric Biggers
Resolves https://github.com/google/fscrypt/issues/305
2021-09-14cmd/fscrypt: recognize no-key names containing hyphenEric Biggers
In Linux 5.15, the no-key name format is changing again; see https://git.kernel.org/linus/ba47b515f5940603. isPossibleNoKeyName() sometimes doesn't recognize the new no-key names. Update it accordingly to recognize all possible no-key names. Note: isPossibleNoKeyName() is only used as a heuristic to check whether a v1-encrypted directory is incompletely locked or not. Therefore, it's not too important whether it works. However, this change is needed for cli-tests/t_v1_policy to pass.
2021-09-14cli-tests/common.sh: remove argument count checksEric Biggers
These confuse the latest version of shellcheck into thinking that functions which take no arguments actually take arguments, which triggers a bunch of warnings like "Use func "$@" if function's $1 should mean script's $1", which causes 'make lint' to fail. These checks aren't too useful, so just remove them.
2021-09-14README: clarify how restoring /.fscrypt directory worksEric Biggers
Update https://github.com/google/fscrypt/issues/115
2021-09-13Merge pull request #310 from ebiggers/readme-updatesJoseph Richey
Readme updates
2021-09-13README: add section about encrypting existing filesEric Biggers
2021-09-13README: consistently format section titlesEric Biggers
Capitalize the first word only, and don't use periods.
2021-09-13README: add section about backup, restore, and recoveryEric Biggers
Resolves https://github.com/google/fscrypt/issues/51 Resolves https://github.com/google/fscrypt/issues/115
2021-09-13README: remove note about stabilityEric Biggers
A lot of people are already using fscrypt, so in practice we haven't been breaking backwards compatibility and aren't going to. Just remove the scary-sounding "Note about stability".
2021-09-13README: remove note about planned commandsEric Biggers
These would still be nice to add. However, the mention of them in the README is misleading because people reading it might come away with the impression that there is currently no way to back up fscrypt metadata or to recover directories -- which isn't true. (The fscrypt metadata is just a directory which can be backed up like any other directory. And 'fscrypt encrypt' already offers to generate a recovery passphrase when the directory and protector are on different filesystems.) Just remove this note; it doesn't really add any value.
2021-08-31Merge pull request #309 from ebiggers/troubleshootingJoseph Richey
Updates to the troubleshooting documentation
2021-08-31README: document symlink size bugEric Biggers
Update https://github.com/google/fscrypt/issues/305
2021-08-31README: documentation tweaksEric Biggers
Clarify some of the troubleshooting documentation.
2021-07-16cli-tests: fix failure with latest bash versionEric Biggers
2021-07-16README: add troubleshooting section for ENOPKG errorEric Biggers
Inspired by https://reddit.com/r/linuxquestions/comments/n75dv4
2021-06-27README: add troubleshooting section for keyring linkage issueEric Biggers
Fixes https://github.com/google/fscrypt/issues/194 Update https://github.com/google/fscrypt/issues/100
2021-06-27cmd/fscrypt: fix detection of GRUB installationEric Biggers
Fix the GRUB detection logic to take into account that MOUNTPOINT/boot/grub might not be on the same filesystem as MOUNTPOINT, due to MOUNTPOINT/boot being another mountpoint. The warning is only appropriate when GRUB is installed on the same filesystem that encryption is going to be enabled on.
2021-06-14README: improve troubleshooting tips for unlocked encrypted filesEric Biggers
Rename the troubleshooting section "Can't log in with ssh even when user's encrypted home directory is unlocked" to the more general "Some processes can't access unlocked encrypted files", and rewrite it to provide clearer directions for how to fix the problem by upgrading encrypted directories to policy version 2. Also add a related section "Users can access other users' unlocked encrypted files" which covers the reverse "issue", i.e. people expecting some processes to *not* be able to access unlocked encrypted files. Fixes https://github.com/google/fscrypt/issues/248
2021-06-09README: improve troubleshooting section for login protector not in syncEric Biggers
Update https://github.com/google/fscrypt/issues/273
2021-05-24Merge pull request #292 from josephlr/memJoseph Richey
Only use 1/8 of the system RAM and run the Garbage Collector in the timing loop
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-10 16:17:31 +0000