[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2dc7318d6c74b27a49b4c64b513f3da13d980473.camel@HansenPartnership.com>
Date: Thu, 12 Jun 2025 14:27:27 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org, Jarkko
Sakkinen <jarkko@...nel.org>, Steve French <sfrench@...ba.org>, Chuck Lever
<chuck.lever@...cle.com>, Mimi Zohar <zohar@...ux.ibm.com>
Cc: Paulo Alcantara <pc@...guebit.org>, Herbert Xu
<herbert@...dor.apana.org.au>, Jeffrey Altman <jaltman@...istor.com>,
hch@...radead.org, linux-afs@...ts.infradead.org,
linux-nfs@...r.kernel.org, linux-cifs@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] Keyrings: How to make them more useful
On Thu, 2025-06-12 at 13:36 +0100, David Howells wrote:
[...]
> Thoughts?
One of the problems I keep tripping over is different special casing
for user keyrings (which are real struct key structures) and system
keyrings which are special values of the pointer in struct key *.
For examples of what this special handling does, just look at things
like bpf_trace.c:bpf_lookup_{user|system}_key
Since the serial allocation code has a hard coded not less than 3
(which looks for all the world like it was designed to mean the two
system keyring id's were never used as user serial numbers) I think we
could simply allow the two system keyring ids to be passed into
lookup_user_key() (which now might be a bit misnamed) and special case
not freeing it in put_key().
Regards,
James
Powered by blists - more mailing lists