All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: jmorris@namei.org
Cc: linux-security-module@vger.kernel.org, keyrings@linux-nfs.org,
	linux-kernel@vger.kernel.org, Jeff Layton <jlayton@redhat.com>,
	David Howells <dhowells@redhat.com>
Subject: [PATCH 2/9] keys: update the description with info about "logon" keys
Date: Wed, 28 Mar 2012 11:46:19 +0100	[thread overview]
Message-ID: <20120328104619.10417.78851.stgit@warthog.procyon.org.uk> (raw)
In-Reply-To: <20120328104607.10417.85745.stgit@warthog.procyon.org.uk>

From: Jeff Layton <jlayton@redhat.com>

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 Documentation/security/keys.txt |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index 7877170..4c8cf36 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -123,7 +123,7 @@ KEY SERVICE OVERVIEW
 
 The key service provides a number of features besides keys:
 
- (*) The key service defines two special key types:
+ (*) The key service defines three special key types:
 
      (+) "keyring"
 
@@ -137,6 +137,19 @@ The key service provides a number of features besides keys:
 	 blobs of data. These can be created, updated and read by userspace,
 	 and aren't intended for use by kernel services.
 
+     (+) "logon"
+
+         Like a "user" key, a "logon" key has a payload that is an arbitrary
+         blob of data. It is intended as a place to store secrets that the
+         to which the kernel should have access but that should not be
+         accessable from userspace.
+
+         The description can be arbitrary, but must be prefixed with a non-zero
+         length string that describes the key "subclass". The subclass is
+         separated from the rest of the description by a ':'. "logon" keys can
+         be created and updated by userspace, but the payload is only readable
+         from kernel space.
+
  (*) Each process subscribes to three keyrings: a thread-specific keyring, a
      process-specific keyring, and a session-specific keyring.
 


  reply	other threads:[~2012-03-28 10:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28 10:46 [PATCH 1/9] KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat David Howells
2012-03-28 10:46 ` David Howells
2012-03-28 10:46 ` David Howells [this message]
2012-03-28 11:28   ` [Keyrings] [PATCH 2/9] keys: update the description with info about "logon" keys Mimi Zohar
2012-04-02 17:07     ` Jeff Layton
2012-04-03  0:48     ` David Howells
2012-03-28 10:46 ` [PATCH 3/9] KEYS: Move the key config into security/keys/Kconfig David Howells
2012-03-28 10:46 ` [PATCH 4/9] KEYS: Reorganise keys Makefile David Howells
2012-03-28 10:46 ` [PATCH 5/9] KEYS: Announce key type (un)registration David Howells
2012-03-28 10:47 ` [PATCH 6/9] KEYS: Perform RCU synchronisation on keys prior to key destruction David Howells
2012-03-28 10:47 ` [PATCH 7/9] KEYS: Permit in-place link replacement in keyring list David Howells
2012-03-28 10:47 ` [PATCH 8/9] KEYS: Do LRU discard in full keyrings David Howells
2012-03-28 10:47 ` [PATCH 9/9] KEYS: Add invalidation support David Howells
2012-03-28 10:52 ` [PATCH 1/9] KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat David Howells
2012-03-28 10:52   ` David Howells
2012-03-28 11:36   ` James Morris
2012-03-28 11:36     ` James Morris
  -- strict thread matches above, loose matches on Subject: below --
2012-02-08 11:02 [PATCH 1/9] KEYS: Allow special keyrings to be cleared David Howells
2012-02-08 11:03 ` [PATCH 2/9] keys: update the description with info about "logon" keys David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120328104619.10417.78851.stgit@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.