keys: request_key_auth shows a global pid in /proc/keys across pid namespaces

[Maoyi Xie]

On Tue, Aug 11, 2026 at 12:50 AM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> I'm afraid this get_pid/put_pid doesn't look right because what it will
> do is pin the pid in the creator pid namespace.  Unfortunately, some
> keys and keyrings aren't bound to a pid namespace, so if I create a key
> in my user keyring and then enter a new pid namespace, with this change
> it will still show up as the pid number of the init namespace (pinning
> the struct pid there) and vice versa, which still sounds like the wrong
> behaviour.

You're right that get_pid() keeps the creator's pid_namespace alive for the
auth key's lifetime. But the pin does not change the printed number. describe()
renders through the reader's proc pid_ns with pid_nr_ns(). That returns 0 when
the task is not visible there. A key made in init_ns and read from a child
pid_ns shows 0, not the init number. It never shows a foreign pid. In your
example the pin only holds init_pid_ns, which is permanent, so it changes
nothing. Auth keys are short-lived, so a container-created key holds that pin
only until request_key finishes.

> I think if you really want to fix this, you have to keep the pid as is,
> but make sure it always records the pid in the init_pid_ns (i.e. always
> translate back to init_ns) and then translate to the current pid_ns in
> the output generator of /proc/keys.

current->pid is already the init_pid_ns number. Keeping a struct pid lets
pid_nr_ns translate it for each reader, the way pidfd_show_fdinfo() already
does. A raw pid_t would instead need a find_pid_ns() lookup at read time. That
can land on a reused number.

Thanks,
Maoyi