keyring: fix permission denied accessing user keyring #177
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 #176
josephlr
approved these changes
Dec 16, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 #176