| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
When userKeyringIDLookup() looks up a user keyring, it links it into the
process keyring to ensure that the process retains the "possessor
privileges" over the user keyring, then caches the user keyring's ID.
Unfortunately, this use of the process keyring randomly fails because Go
creates threads before even init() and main() are run, and then can run
code on them later. Since the kernel doesn't create the process keyring
until userspace requests it and the process keyring is actually a
per-thread property that's only inherited by new threads, different
threads in a Go process may see different process keyrings.
Fix this by removing the user keyring cache, switching from the process
keyring to the thread keyring, and using LockOSThread() to pin the
goroutine to an OS thread while needed to perform a keyring operation.
Resolves https://github.com/google/fscrypt/issues/176
|
|
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".
|
|
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().
|
|
* Remove spelling mistakes in the repository
* Add travis script to check for typos.
* Add command to Makefile to check for typos.
* Fixes #71
|
|
This change makes sure that, when we set the ruid and euid in order to
get the user keyring linked into the current process keyring, we will
always be able to reverse these changes (using a suid of 0).
This fixes an issue where "su <user>" would result in a system error
when called by an unprivileged user. It also explains exactly how and
why we are making these privilege changes.
|
|
|
|
|
|
Now instead of spawning a seperate thread we alternate between changing
the euid and ruid to both find the keyring and link it to the process
keyring. Note that we also ensure that the user keyring is linked into
the root keyring whenever possible.
|
|
|
|
|
|
The keyring lookup functions no longer read from /proc/keys. Now they
simply spawn a thread, drop privs, and check with GetKeyringID and
KEY_SPEC_USER_KEYRING. See userKeyringID() for more info.
The privileges functions have also been changed. Now the concept of
setting privileges is seperate form the concept of setting up the
keyrings.
|
|
|
|
|
|
|
|
|
