Message-ID: <1457447480.5321.115.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: Tue, 08 Mar 2016 09:31:20 -0500
In-Reply-To: <30699.1457442839@warthog.procyon.org.uk>
References: <1457402735.5321.14.camel@linux.vnet.ibm.com>
	 <20160304150022.17121.34501.stgit@warthog.procyon.org.uk>
	 <20160304150142.17121.56666.stgit@warthog.procyon.org.uk>
	 <30699.1457442839@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: 723
Lines: 17

On Tue, 2016-03-08 at 13:13 +0000, David Howells wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > but we're left with a lot of references to "system_trusted" (eg.
> > restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING
> 
> How about I pluralise it to SYSTEM_TRUSTED_KEYRINGS?  The fact that one is
> called builtin and the other secondary doesn't detract from the fact that
> they're both system-wide rings of trusted keys.

Would then restrict_link_to_system_trusted imply both the builtin and
secondary keyrings or just the builtin keyrings?   Changing the system
keyring name to builtin keys, without changing the corresponding
restrict_link name, obfuscates what is really happening.

Mimi