Message-ID: <1457402735.5321.14.camel@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that
 can be added to dynamically [ver #2]
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date: Mon, 07 Mar 2016 21:05:35 -0500
In-Reply-To: <20160304150142.17121.56666.stgit@warthog.procyon.org.uk>
References: <20160304150022.17121.34501.stgit@warthog.procyon.org.uk>
	 <20160304150142.17121.56666.stgit@warthog.procyon.org.uk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1119
Lines: 25

On Fri, 2016-03-04 at 15:01 +0000, David Howells wrote:
> Add a secondary system keyring that can be added to by root whilst the
> system is running - provided the key being added is vouched for by a key
> built into the kernel or already added to the secondary keyring.
> 
> Rename .system_keyring to .builtin_trusted_keys to distinguish it more
> obviously from the new keyring (called .secondary_trusted_keys).

Renaming of the system_trusted_keyring to builtin_trusted_keys is fine,
but we're left with a lot of references to "system_trusted" (eg.
restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING,  the
subsequent patch description and Kconfig use "system trusted keyrings",
etc).   Without changing these references, I'm not convinced this is an
improvement. 

Mimi

> The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.
> 
> If the secondary keyring is enabled, a link is created from that to
> .builtin_trusted_keys so that the the latter will automatically be searched
> too if the secondary keyring is searched.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>