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

["Gary Guo" <gary@garyguo.net>]

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