| Age | Commit message (Collapse) | Author |
|---|
|
Don't force the user to provide a --user argument when running fscrypt
as root if they're doing something where the TargetUser isn't actually
needed, such as provisioning/deprovisioning a v1 encryption policy
to/from the filesystem keyring, or creating a non-login protector.
Also don't set up the user keyring (or check for it being set up) if it
won't actually be used.
Finally, if we'll be provisioning/deprovisioning a v1 encryption policy
to/from the filesystem keyring, make sure the command is running as
root, since the kernel requires this.
|
|
In preparation for introducing support for the new filesystem-level
keyrings, move the existing user keyring management code from
security/keyring.go and crypto/crypto.go into a new package, 'keyring'.
This package provides functions AddEncryptionKey, RemoveEncryptionKey,
and GetEncryptionKeyStatus which delegate to either the filesystem
keyring (added by a later patch) or to the user keyring. This provides
a common interface to both types of keyrings, to the extent possible.
|
|
Refer to the target User as 'targetUser' rather than simply 'target'.
This will help avoid confusion when we add support for the filesystem
keyring, since then the Mount will also be a "target".
|
|
* Remove spelling mistakes in the repository
* Add travis script to check for typos.
* Add command to Makefile to check for typos.
* Fixes #71
|
|
|
|
|
|
Chaning the --user flag to (optionally) check for a proper keyring setup
allows us to fail early in cases where we need a working keyring.
|
|
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.
|
|
|
|
|
|
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
|
|
This commit adds in the framework for adding commands and subcommands to
the fscrypt tool. This commit adds in the "setup", "encrypt", and
"unlock" commands. Additional information can be found by running:
fscrypt <command> --help.
This commit defines how flags are parsed and errors are handled. It also
creates an extensible framework for prompting the user for information.
Change-Id: I159d7f44ee2b2bbc5e072f0802850e082d9a13ce
|
