Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement key management (keyctl and friends) #30

Open
3 tasks
rrnewton opened this issue Nov 30, 2022 · 0 comments
Open
3 tasks

Implement key management (keyctl and friends) #30

rrnewton opened this issue Nov 30, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@rrnewton
Copy link
Contributor

rrnewton commented Nov 30, 2022

This is a currently unhandled piece of Linux functionality that we just "let through". But it introduces nondeterminism in the key_serial_t identifiers that come back.

Basic plan:

  • virtualize the key serials just like with other IDs (e.g. inodes)
  • make sure that our container setup keeps the process tree's keys separate from anything else on the system

Specific steps for virtualizating IDs would include:

  • add a new global state RPC for adding/resolving key serial numbers
  • have local handlers for add_key establish the new virtual mapping, and return the virtual serial ID to the guest, which probably starts at a constant and counts up by +1
  • have request_key and keyctl calls resolve virtual serial numbers before issuing to Linux

Relevant manpages:

@rrnewton rrnewton added the enhancement New feature or request label Nov 30, 2022
facebook-github-bot pushed a commit that referenced this issue Dec 7, 2022
Summary: These were not being mentioned at all in the syscall subscription list, but they are a source of nondeterminism, as described in issue #30.

Reviewed By: VladimirMakaev

Differential Revision: D41613558

fbshipit-source-id: f481fc9baf3e05467ad2f6e0a97b9023b6a24a34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant