aboutsummaryrefslogtreecommitdiff
path: root/cmd/fscrypt/status.go
AgeCommit message (Collapse)Author
2020-05-09filesystem: improve errorsEric Biggers
Introduce filesystem.ErrEncryptionNotEnabled and filesystem.ErrEncryptionNotSupported which include the Mount as context, and translate the corresponding metadata/ errors into them. Then make these errors show much better suggestions. Also replace lots of other filesystem/ errors with either custom types or with unnamed one-off errors that include more context. Fix backwards wrapping in lots of cases. Finally, don't include the mountpoint in places where it's not useful, like OS-level errors that already include the path.
2020-05-09Try to detect incomplete locking of v1-encrypted directoryEric Biggers
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use files, as the kernel doesn't provide a way to easily detect it. Instead, implement a heuristic where we check whether a subdirectory can be created. If yes, then the directory must not be fully locked. Make both 'fscrypt lock' and 'fscrypt status' use this heuristic. Resolves https://github.com/google/fscrypt/issues/215
2020-01-05Keyring support for v2 encryption policiesEric Biggers
Implement adding/removing v2 encryption policy keys to/from the kernel. The kernel requires that the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY be used for this. Root is not required. However, non-root support brings an extra complication: the kernel keeps track of which users have called FS_IOC_ADD_ENCRYPTION_KEY for the same key. FS_IOC_REMOVE_ENCRYPTION_KEY only works as one of these users, and it only removes the calling user's claim to the key; the key is only truly removed when the last claim is removed. Implement the following behavior: - 'fscrypt unlock' and pam_fscrypt add the key for the user, even if other user(s) have it added already. This behavior is needed so that another user can't remove the key out from under the user. - 'fscrypt lock' and pam_fscrypt remove the key for the user. However, if the key wasn't truly removed because other users still have it added, 'fscrypt lock' prints a warning. - 'fscrypt status' shows whether the directory is unlocked for anyone.
2020-01-05keyring: support filesystem keyring with v1 encryption policiesEric Biggers
Linux v5.4 and later allows fscrypt keys to be added/removed directly to/from the filesystem via the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY. Among other benefits, these fix the key visibility problems that many users have been running into, where system services and containers can't access encrypted files. Allow the user to opt-in to using these new ioctls for their existing encrypted directories by setting in their /etc/fscrypt.conf: "use_fs_keyring_for_v1_policies": true Note that it can't really be on by default, since for v1 policies the ioctls require root, whereas user keyrings don't. I.e., setting this to true means that users will need to use 'sudo fscrypt unlock', not 'fscrypt unlock'. v2 policies won't have this restriction.
2019-10-29filesystem: rename Mount.Filesystem to Mount.FilesystemTypeEric Biggers
Make it clear that this refers to a type of filesystem such as "ext4", rather than to a specific filesystem instance.
2019-09-09cmd/fscrypt: show encryption options with 'fscrypt status DIR' (#145)ebiggers
Show the encryption options when running 'fscrypt status' on a directory. E.g.: Policy: 490515286453d3f7 Options: padding:32 contents:Adiantum filenames:Adiantum Unlocked: Yes
2019-09-08Fix various typos and grammatical errors (#141)ebiggers
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().
2017-08-30cmd/fscrypt: Add --user flag for running as rootJoe Richey
The --user flag can now be used to have the targe user (the one whose keyring and password will be used in fscrypt) be different than the calling user. Very usefull for things like sudo fscrypt purge /media/joerichey/usb --user=joerichey which will now have privileges to drop caches, but will properly clear the keys from the user's keyring.
2017-07-17cmd/fscrypt: Improve "fscrypt status"Joe Richey joerichey@google.com
Now that we can distinguish between lacking encryption support and lacking fscrypt metadata, "fscrypt status" can now display this additional information.
2017-06-28Finalize import paths and documentationv0.1.00.1.0Joe Richey joerichey@google.com
This commit changes all the internal import paths from `fscrypt/foo` to `github.com/google/fscrypt/foo` so that it can be built once we release externaly. The documentation in README.md is updated accordingly. Also, the README has a note noting that we do not make any guarantees about project stability before 1.0 (when it ships with Ubuntu). Change-Id: I6ba86e442c74057c8a06ba32a42e17f94833e280
2017-06-28cmd/fscrypt: add in status and purge commandsJoe Richey joerichey@google.com
This commit adds in the status command, which has 2 functions, allowing the user to query the state of the entire system or a specific filesystem. This commit also adds in the purge command to remove all policy keys corresponding to a filesystem. This (along with getting the unlock status for the status commands) uses additional keyctl functionality in the crypto and actions packages. Change-Id: Ic8e097b335c044c0b91973eff19753f363f4525d