[PATCH] keys: allow request-key path to be configured via Kconfig

[PATCH] keys: allow request-key path to be configured via Kconfig

[Gary Guo]

From: Gary Guo <gary@garyguo.net>

Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
currently carry patches to replace /sbin/request-key to some other path.

Follow the way modprobe handles this by making this a Kconfig option which
defaults to the current /sbin/request-key.

Also changed "char const" to "const char" as checkpatch complains
otherwise.

Link: https://github.com/NixOS/nixpkgs/blob/6b316287bae2ee04c9b93c8c858d930fd07d7338/pkgs/os-specific/linux/kernel/request-key-helper.patch
Signed-off-by: Gary Guo <gary@garyguo.net>
---
I did not update mentions of /sbin/request-key in documentation and
elsewhere, as "/sbin/request-key" is concise while "request-key UMH" is
more mouthful and less clear.

Number of distros that doesn't have /sbin is limited so I think it wouldn't
create much confusion. Similarly, there are a lot of places where
/sbin/modprobe is mentioned despite it is technically configurable.
---
 security/keys/Kconfig       | 9 +++++++++
 security/keys/request_key.c | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index f4510d8cb485..ee3c3d85fc03 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -40,6 +40,15 @@ config KEYS_REQUEST_CACHE
 	  key.  Pathwalk will call multiple methods for each dentry traversed
 	  (permission, d_revalidate, lookup, getxattr, getacl, ...).
 
+config REQUEST_KEY_PATH
+	string "Path to the request-key binary"
+	default "/sbin/request-key"
+	help
+	  Path of the request-key usermode helper binary.
+
+	  This program is invoked by the kernel when the kernel is asked for
+	  a key that it doesn't have immediately available.
+
 config PERSISTENT_KEYRINGS
 	bool "Enable register of persistent per-UID keyrings"
 	help
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index a7673ad86d18..ac8f9d1a87ad 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -117,7 +117,7 @@ static int call_usermodehelper_keys(const char *path, char **argv, char **envp,
  */
 static int call_sbin_request_key(struct key *authkey, void *aux)
 {
-	static char const request_key[] = "/sbin/request-key";
+	static const char request_key[] = CONFIG_REQUEST_KEY_PATH;
 	struct request_key_auth *rka = get_request_key_auth(authkey);
 	const struct cred *cred = current_cred();
 	key_serial_t prkey, sskey;

base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
-- 
2.54.0

Re: [PATCH] keys: allow request-key path to be configured via Kconfig

[Serge E. Hallyn]

On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
> From: Gary Guo <gary@garyguo.net>
> 
> Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
> currently carry patches to replace /sbin/request-key to some other path.
> 
> Follow the way modprobe handles this by making this a Kconfig option which
> defaults to the current /sbin/request-key.
> 
> Also changed "char const" to "const char" as checkpatch complains
> otherwise.
> 
> Link: https://github.com/NixOS/nixpkgs/blob/6b316287bae2ee04c9b93c8c858d930fd07d7338/pkgs/os-specific/linux/kernel/request-key-helper.patch
> Signed-off-by: Gary Guo <gary@garyguo.net>

Reviewed-by: Serge Hallyn <serge@hallyn.com>

> ---
> I did not update mentions of /sbin/request-key in documentation and
> elsewhere, as "/sbin/request-key" is concise while "request-key UMH" is
> more mouthful and less clear.
> 
> Number of distros that doesn't have /sbin is limited so I think it wouldn't
> create much confusion. Similarly, there are a lot of places where
> /sbin/modprobe is mentioned despite it is technically configurable.
> ---
>  security/keys/Kconfig       | 9 +++++++++
>  security/keys/request_key.c | 2 +-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index f4510d8cb485..ee3c3d85fc03 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -40,6 +40,15 @@ config KEYS_REQUEST_CACHE
>  	  key.  Pathwalk will call multiple methods for each dentry traversed
>  	  (permission, d_revalidate, lookup, getxattr, getacl, ...).
>  
> +config REQUEST_KEY_PATH
> +	string "Path to the request-key binary"
> +	default "/sbin/request-key"
> +	help
> +	  Path of the request-key usermode helper binary.
> +
> +	  This program is invoked by the kernel when the kernel is asked for
> +	  a key that it doesn't have immediately available.
> +
>  config PERSISTENT_KEYRINGS
>  	bool "Enable register of persistent per-UID keyrings"
>  	help
> diff --git a/security/keys/request_key.c b/security/keys/request_key.c
> index a7673ad86d18..ac8f9d1a87ad 100644
> --- a/security/keys/request_key.c
> +++ b/security/keys/request_key.c
> @@ -117,7 +117,7 @@ static int call_usermodehelper_keys(const char *path, char **argv, char **envp,
>   */
>  static int call_sbin_request_key(struct key *authkey, void *aux)
>  {
> -	static char const request_key[] = "/sbin/request-key";
> +	static const char request_key[] = CONFIG_REQUEST_KEY_PATH;
>  	struct request_key_auth *rka = get_request_key_auth(authkey);
>  	const struct cred *cred = current_cred();
>  	key_serial_t prkey, sskey;
> 
> base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
> -- 
> 2.54.0

Re: [PATCH] keys: allow request-key path to be configured via Kconfig

[Jarkko Sakkinen]

On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
> From: Gary Guo <gary@garyguo.net>
> 
> Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
> currently carry patches to replace /sbin/request-key to some other path.

Sorry but no configuration for introducing API divergence.


> 
> Follow the way modprobe handles this by making this a Kconfig option which
> defaults to the current /sbin/request-key.
> 
> Also changed "char const" to "const char" as checkpatch complains
> otherwise.
> 
> Link: https://github.com/NixOS/nixpkgs/blob/6b316287bae2ee04c9b93c8c858d930fd07d7338/pkgs/os-specific/linux/kernel/request-key-helper.patch
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---
> I did not update mentions of /sbin/request-key in documentation and
> elsewhere, as "/sbin/request-key" is concise while "request-key UMH" is
> more mouthful and less clear.
> 
> Number of distros that doesn't have /sbin is limited so I think it wouldn't
> create much confusion. Similarly, there are a lot of places where
> /sbin/modprobe is mentioned despite it is technically configurable.
> ---
>  security/keys/Kconfig       | 9 +++++++++
>  security/keys/request_key.c | 2 +-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index f4510d8cb485..ee3c3d85fc03 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -40,6 +40,15 @@ config KEYS_REQUEST_CACHE
>  	  key.  Pathwalk will call multiple methods for each dentry traversed
>  	  (permission, d_revalidate, lookup, getxattr, getacl, ...).
>  
> +config REQUEST_KEY_PATH
> +	string "Path to the request-key binary"
> +	default "/sbin/request-key"
> +	help
> +	  Path of the request-key usermode helper binary.
> +
> +	  This program is invoked by the kernel when the kernel is asked for
> +	  a key that it doesn't have immediately available.
> +
>  config PERSISTENT_KEYRINGS
>  	bool "Enable register of persistent per-UID keyrings"
>  	help
> diff --git a/security/keys/request_key.c b/security/keys/request_key.c
> index a7673ad86d18..ac8f9d1a87ad 100644
> --- a/security/keys/request_key.c
> +++ b/security/keys/request_key.c
> @@ -117,7 +117,7 @@ static int call_usermodehelper_keys(const char *path, char **argv, char **envp,
>   */
>  static int call_sbin_request_key(struct key *authkey, void *aux)
>  {
> -	static char const request_key[] = "/sbin/request-key";
> +	static const char request_key[] = CONFIG_REQUEST_KEY_PATH;
>  	struct request_key_auth *rka = get_request_key_auth(authkey);
>  	const struct cred *cred = current_cred();
>  	key_serial_t prkey, sskey;
> 
> base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
> -- 
> 2.54.0
> 

BR, Jarkko

Re: [PATCH] keys: allow request-key path to be configured via Kconfig

[Jarkko Sakkinen]

On Mon, Jun 08, 2026 at 07:50:03AM +0300, Jarkko Sakkinen wrote:
> On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
> > From: Gary Guo <gary@garyguo.net>
> > 
> > Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
> > currently carry patches to replace /sbin/request-key to some other path.
> 
> Sorry but no configuration for introducing API divergence.

Not sure right now but one option might kernel command-line. Then it is
known at run-time, can be signed etc. Compiled value has no identity in
the same way.

And I don't care if NixOS has such a problem as I've not have any stake
making of those decisions.

You really should explain why it makes sense to have such feature i.e.,
why is it useful. And if NixOS considered, why is it useful for NixOS.

This all should be in  the commit message.

BR, Jarkko

Re: [PATCH] keys: allow request-key path to be configured via Kconfig

[Gary Guo]

On Mon Jun 8, 2026 at 5:59 AM BST, Jarkko Sakkinen wrote:
> On Mon, Jun 08, 2026 at 07:50:03AM +0300, Jarkko Sakkinen wrote:
>> On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
>> > From: Gary Guo <gary@garyguo.net>
>> > 
>> > Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
>> > currently carry patches to replace /sbin/request-key to some other path.
>> 
>> Sorry but no configuration for introducing API divergence.

What is the API divergence here? Distros can already patch the kernel or place a
different binary there, so I don't see what's being gained on not allowing to
change this with Kconfig.

Also to note, the actual binary being called can already be swapped out by
CONFIG_STATIC_USERMODEHELPER_PATH, although for the NixOS this is not the proper
mechanism as it affects coredump too which isn't a fixed path binary in /sbin.

This is really just for distros to be able to configure where /sbin is located.
Given usr merge and (some distros) bin/sbin merge, the canonical path of
request-key binary is very likely not /sbin/request-key anymore, so it seems to
make sense to me to allow this to be changed rather than always go through
compatibility symlinks.

How about a something like CONFIG_DEFAULT_USERMODEHELPER_PATH which defaults to
/sbin, and then request-key uses that concatenated with "/request-key"?

>
> Not sure right now but one option might kernel command-line. Then it is
> known at run-time, can be signed etc. Compiled value has no identity in
> the same way.
>
> And I don't care if NixOS has such a problem as I've not have any stake
> making of those decisions.
>
> You really should explain why it makes sense to have such feature i.e.,
> why is it useful. And if NixOS considered, why is it useful for NixOS.
>
> This all should be in  the commit message.

Sure, if you need some more detailed explaination on how NixOS works.

NixOS intentionally not use FHS directory paths, so packages refers to their
dependencies via cryptographical hashes in rather than fixed paths for build-time
known dependencies, and themselves also live in a path with hashes in them (so
two different versions of the same package are in different paths). E.g.
/nix/store/wjzk0s5dwk0i7swh3rmh1pl10k6v1w6d-keyutils-1.6.3/bin/request-key

The full system is also built as a package with all installed binaries in
$pkg/sw/bin, configuration in $pkg/etc, etc.. The current system is symlinked to
/run/current-system, and when a new system is activated this symlink is swapped
out and therefore all paths are updated atomically. For request-key, this is
symlinked to
/run/current-system/sw/bin/request-key

NixOS carries a patch which uses this path instead of /sbin (which does not
exist on NixOS at all).

The motivation is really "be able to switch /sbin". I feel that all the above are
secondary motivations and is too verbose to include in the commit message.

I am not a maintainer for NixOS's kernel; I use NixOS and just want to develop
kernel and test out kernel on my machines without having to patch them.

Best,
Gary