-
Notifications
You must be signed in to change notification settings - Fork 568
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
Add keyutils to CBL-Mariner base image #8810
Comments
It should be noted that the AzureLinux kernel config includes
which depend upon the presence of /sbin/request-key from the keyutils package. |
I'd love this! |
We can |
@mfrw thank you for the reply. The Linux kernel version doesn't matter to this request. All Linux kernels due to keyrings support will perform an upcall to userspace by executing /sbin/request-key from the namespace of the root filesystem mount. This same upcall mechanism will be used for DNS queries when the kernel is built with CONFIG_DNS_RESOLVE=y. Successful execution of the upcall requires that /sbin/request-key must be present in the root filesystem's namespace. The kernel cannot successfully find or execute /sbin/request-key when tdnf (or other package manager) is used to install /sbin/request-key (as part of the keyutils package) into a container image filesystem because the container image filesystem is mounted into a distinct namespace. If the kernel could find and execute /sbin/request-key in the container namespace, a container could replace the host's binaries and configuration for the purpose of feeding inappropriate data into the kernel which would then apply to the host at large and all of the other containers running on the system. What I am asking for in this request is that the keyutils package be added to the CBL-Mariner base image so that /sbin/request-key and its required configuration and associated helpers are available in the root filesystem namespace. A simple test of the /sbin/request-key upcall is to execute
if /sbin/request-key is not present in the root filesystem it will fail with a "No such file or directory" error. (-ENOENT). This will be true even if /sbin/request-key is present in the Debian, Ubuntu, AzureLinux container image. |
Hi, @OneBlue as discussed at your ignite session here is what I think the key issue is w.r.t. support DFS CIFS shares in WSL2. The DFS kernel code requires kernel upcalls to work to resolve dns: see: https://github.com/torvalds/linux/blob/fc39fb56917bb3cb53e99560ca3612a84456ada2/fs/smb/client/dns_resolve.c#L68C7-L68C16 Installing any linux distribution on WSL2 and running the following to test request-key functionality shows it doesn't work:
This is something that needs to be fixed in the image you run wsl2 distributions in I believe. Issue realted to kernel dns resolver not working in WSL2: microsoft/WSL#9540 Thanks for looking! |
Hi, Thanks for posting this, can anybody think of a workaround to the missing keyutils/request-key issue? Also trying to get DFS to run. thank you br francesco |
Hi @OneBlue, happy 2025. I was wondering if you had an update on this item? |
Is your feature request related to a problem? Please describe.
Bug reports have been filed against WSL2 because of failures of the Linux Kernel's Key Request Service. The Key Request Service provides an upcall mechanism as documented in Documentation/security/keys/request-key.rst where the kernel executes an instance of /sbin/request-key for each request. The request-key process is provided by the keyutils package. If the /sbin/request-key process cannot be located in the mount namespace of the root filesystem, then the upcalls will fail with an -ENOENT error. The Key Request service is used in support of keyring management, DNS queries, and id-mapping.
Describe the solution you'd like
Please install keyutils as part of the base image
Describe alternatives you've considered
Installation of keyutils in an WSL2 distro container does not work because the installed /sbin/request-key cannot be located in the mount namespace of the root filesystem.
Additional context
A working key request service is necessary to support various Linux kernel options including
The text was updated successfully, but these errors were encountered: