[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

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

[Jarkko Sakkinen]

On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> 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.

There's lot of out-of-tree drivers too that distributions. I'm not
finding anything usefel in this argument.

> 
> 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.

I have not seen actual uses of CONFIG_STATIC_USERMODEHELPER_PATH. You
could probably use it with busybox?

> 
> 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.

I doubt there's a huge demand other than NixOS. Just basing this on that
no other noise have been made so far.

> 
> 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.

I don't frankly care how NixOS works per se in details. Scope this into
message to problem that it addresses.

> 
> Best,
> Gary

BR, Jarkko

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

[Jarkko Sakkinen]

On Wed, Jun 10, 2026 at 03:57:37PM +0300, Jarkko Sakkinen wrote:
> On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> > 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.
> 
> There's lot of out-of-tree drivers too that distributions. I'm not
> finding anything usefel in this argument.
> 
> > 
> > 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.
> 
> I have not seen actual uses of CONFIG_STATIC_USERMODEHELPER_PATH. You
> could probably use it with busybox?
> 
> > 
> > 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.
> 
> I doubt there's a huge demand other than NixOS. Just basing this on that
> no other noise have been made so far.
> 
> > 
> > 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.
> 
> I don't frankly care how NixOS works per se in details. Scope this into
> message to problem that it addresses.

Not 100% NAK but this does not have "universal logic" embedded into it"

"Distro's use it" is popularity opinion, which has no place over here.
Mastodon, Threads etc. work for that so much better.

Perhaps if the motivation-stimuli-solution type of logics gets carved
crystal clear we can move forward. I.e. you need to work on this. I've
given my feedback for this version, and it is not good enough, sorry.

BR, Jarkko

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

[Gary Guo]

On Wed Jun 10, 2026 at 2:01 PM BST, Jarkko Sakkinen wrote:
> On Wed, Jun 10, 2026 at 03:57:37PM +0300, Jarkko Sakkinen wrote:
>> On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
>> > 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.
>> 
>> There's lot of out-of-tree drivers too that distributions. I'm not
>> finding anything usefel in this argument.

Out-of-tree drivers are, well, out of tree. This one requires patching the tree.
Unlike many other distros, so far the only patches needed for NixOS is patching
out /sbin.

>> 
>> > 
>> > 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.
>> 
>> I have not seen actual uses of CONFIG_STATIC_USERMODEHELPER_PATH. You
>> could probably use it with busybox?

I think it's used for hardening.

>> > 
>> > 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.
>> 
>> I doubt there's a huge demand other than NixOS. Just basing this on that
>> no other noise have been made so far.
>> 
>> > 
>> > How about a something like CONFIG_DEFAULT_USERMODEHELPER_PATH which defaults to
>> > /sbin, and then request-key uses that concatenated with "/request-key"?
>> > 
>> > [snip]
>> 
>> I don't frankly care how NixOS works per se in details. Scope this into
>> message to problem that it addresses.

Well, I reckon that's what's going to happen, so in the commit message I just
included "binary is not in /sbin". But the idea is that there's a good reason
that it's not in /sbin.

>
> Not 100% NAK but this does not have "universal logic" embedded into it"
>
> "Distro's use it" is popularity opinion, which has no place over here.
> Mastodon, Threads etc. work for that so much better.

I disagree. Distro is really just a collection of users. I would rather than
phrase this as "user's using it this way". If something needs to be patched to
be used, I think that's rather a good reason to make the change.

I think "user wants to control where UMH lives" is a pretty good motivation, but
it looks like you disagree. Anyhow, if you don't like the idea, I'll just drop
this patch, as I am not the one maintaining these distro patches anyway. I just
think it's the best if Kconfig can meet user demand and more people can run
unpatched kernels.

Best,
Gary

> Perhaps if the motivation-stimuli-solution type of logics gets carved
> crystal clear we can move forward. I.e. you need to work on this. I've
> given my feedback for this version, and it is not good enough, sorry.
>
> BR, Jarkko

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

[Gary Guo]

On Wed Jun 10, 2026 at 1:57 PM BST, Jarkko Sakkinen wrote:
> On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
>> 
>> 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.
>
> I doubt there's a huge demand other than NixOS. Just basing this on that
> no other noise have been made so far.

Just to add on this, both Fedora and openSUSE for example changes their
CONFIG_MODPROBE_PATH to be /usr/sbin/modprobe after /usr merge. They still have
the /sbin -> /usr/sbin symlink available, so it's not like they cannot work with
/sbin/request-key, but I would think that if the option is available then they
might switch to use /usr/sbin/request-key, too.

After all, why would one perform a symlink walk for no reason?

Best,
Gary

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

[Jarkko Sakkinen]

On Wed, Jun 10, 2026 at 02:37:41PM +0100, Gary Guo wrote:
> On Wed Jun 10, 2026 at 1:57 PM BST, Jarkko Sakkinen wrote:
> > On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> >> 
> >> 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.
> >
> > I doubt there's a huge demand other than NixOS. Just basing this on that
> > no other noise have been made so far.
> 
> Just to add on this, both Fedora and openSUSE for example changes their
> CONFIG_MODPROBE_PATH to be /usr/sbin/modprobe after /usr merge. They still have
> the /sbin -> /usr/sbin symlink available, so it's not like they cannot work with
> /sbin/request-key, but I would think that if the option is available then they
> might switch to use /usr/sbin/request-key, too.
> 
> After all, why would one perform a symlink walk for no reason?
> 
> Best,
> Gary

It's not who is right or who is wrong. "The representation
of the argument" is not working here.

Back to the drawing board...

BR, Jarkko