Projects/Keyring collection cache - Revision history

Ghudson at 13:38, 4 October 2013

2013-10-04T13:38:20Z

Ghudson at 14:53, 2 October 2013

2013-10-02T14:53:37Z

Ghudson at 22:50, 27 September 2013

2013-09-27T22:50:14Z

Ghudson at 21:25, 28 August 2013

2013-08-28T21:25:29Z

Simo: /* New credential cache collection schema */

2013-08-28T20:50:44Z

‎New credential cache collection schema

Ghudson at 18:58, 21 August 2013

2013-08-21T18:58:57Z

Simo: /* New Credential Cache Collection schema */

2013-08-20T18:51:58Z

‎New Credential Cache Collection schema

Simo: /* Augmenting the current KEYRING cache type */

2013-08-20T18:51:28Z

‎Augmenting the current KEYRING cache type

Simo at 18:49, 20 August 2013

2013-08-20T18:49:08Z

Simo: /* Background and previous work */

2013-08-20T18:06:05Z

‎Background and previous work

← Older revision		Revision as of 13:38, 4 October 2013
Line 1:		Line 1:
−	{{project-~~target~~\|1.12}}	+	{{project-rel\|1.12}}
−	{{project-review\|2013-10-04}}

	= Scope =		= Scope =

← Older revision		Revision as of 14:53, 2 October 2013
Line 112:		Line 112:
	\_ ...		\_ ...
	\_ krb_ccache:primary (krb_ccache_12WEF43f2)		\_ krb_ccache:primary (krb_ccache_12WEF43f2)
		+
		+	= Testing =
		+
		+	The new keyring functionality will be tested using the t_cccol.c and t_cc.c test programs, the existing tests in t_ccache.py, and new tests added to t_ccache.py to check for legacy session cache linkage.
		+
		+	= Documentation =
		+
		+	The KEYRING credential cache type is currently undocumented. If time permits, doc/basic/ccache_def.rst will be created and will document all credential types, including KEYRING with its new functionaliy.
		+
		+	= Mailing list discussions =
		+
		+	* http://mailman.mit.edu/pipermail/krbdev/2013-August/011648.html
		+	* http://mailman.mit.edu/pipermail/krbdev/2013-September/011774.html
		+
		+	= Commits =
		+
		+	* 620275cd43e237ab273b726b2aee0ae729587772 Add ccache collection tests using API
		+	* d7b94742daae85329067b126d0a4bc5b2ea7e4a0 Improve kinit output credential cache selection
		+	* 1f1b76ab8937c2cb0273cc5d8a7ee806240e1879 Add "which" function to k5test
		+	* 75b7ea9163e57ff0522f55a9cd0c2ab4b4974e38 Defer KEYRING key creation until initialize
		+	* 253155e1db678546358b69ab953f8fdd9b7fb23a Clarify variable names in cc_keyring.c
		+	* c1e8d03a6254e3ce86a71eed31e4c127e3324f9b Add collection support for KEYRING ccache type
		+	* 7c69a0372db5b7ed670ef3099a97942ede7a4739 Support new KEYRING anchor names and big_key keys
		+	* 5d03cb6b235f0ee0e30b34630f95f208d6acd3d0 Conditionally test KEYRING ccache type
		+
		+	= Tickets =
		+
		+	http://krbdev.mit.edu/rt/Ticket/Display.html?id=7711
		+
		+	= Release notes =
		+
		+	Administrator experience:
		+
		+	* Add collection support to the KEYRING credential cache type on Linux, and add support for persistent user keyrings and larger credentials on systems which support them.

← Older revision		Revision as of 22:50, 27 September 2013
Line 1:		Line 1:
−	{{project-~~early~~}}	+	{{project-target\|1.12}}
		+	{{project-review\|2013-10-04}}

	= Scope =		= Scope =

@@ Line 17: / Line 17: @@
 The current implementation creates a new keyring named after the residual and links it to either the session, process, or thread special keyrings.
-This keyring contains one special key named "__krb5_princ__" which contains the ccache principal name.  Each credential is stored as a separate key in the same keyring.  The __krb5_princ__ key and the credential keys use the "user" key type and contain serialized representations of the principal name or credential as appropriate.
+This keyring contains one special key named "__krb5_princ__" which contains the cache principal name.  Each credential is stored as a separate key in the same keyring.  The __krb5_princ__ key and the credential keys use the "user" key type, and contain serialized representations of the principal name or credential as appropriate.
 Example:
@@ Line 63: / Line 63: @@
 The session and user keyrings use the session and user keyrings respectively.  The new "persistent" form uses a special keyring as provided by the new keyutils call keyctl_get_persistent().  It requires support from the kernel for this new type; otherwise, it will fall back to the user keyring and the "user" key type.
-Individual ccaches within the collection are identified and displayed by appending the specific ccache keyring name to the main residual.  For example:
+Individual caches within the collection are identified and displayed by appending the specific cache keyring name to the main residual.  For example:
   KEYRING:persistent:123:krb_ccache_WE324ffdX
@@ Line 69: / Line 69: @@
 == New credential cache collection schema ==
 Examples:

@@ Line 72: / Line 72: @@
 Each credential cache in the collection has a name of the form "krb_ccache_XXXXXX", where XXXXXX is a unique string.  The name of the currently active ccache is stored into a key named "krb_ccache:primary".
-For the "thread", "process", "session", and "user" residual forms, the ccache keyring is stored in a keyring named with the <name> part of the residual and linked into the appropriate special keyring.  For the "persistent" form, the ccache keyring is named "_krb" and is linked to the persistent keyring.  For backwards compatibility, the classic session residual form (the one identified by KEYRING:<name>) uses the <name> part of the residual for the first cache, and the other caches in the collection reside directly in the session keyring alongside the first one.
+For the "thread", "process", "session", and "user" residual forms, the ccache keyring is stored in a keyring named "_krb_<name>" where <name> is the main part of the residual and linked into the appropriate special keyring.  For the "persistent" form, the ccache keyring is named "_krb" and is linked to the persistent keyring.  For backwards compatibility, the classic session residual form (the one identified by KEYRING:<name>) uses the <name> part of the residual for the first cache too, and the first ccache is linked both in the session keyring directly as well as the "_krb_<name>" collection keyring.
 The format of a ccache keyring is unchanged from the classic scheme.
@@ Line 83: / Line 83: @@
       \_ krbtgt/TEST.KERBEROS.ORG@TEST.KERBEROS.ORG
       \_ ...
 * KRB5CCNAME=KEYRING:user:testusercc
  user
       \_ krb_ccache_12WEF43f2
           \_ __krb5_princ__

@@ Line 3: / Line 3: @@
 = Scope =
 = Background and previous work =
@@ Line 11: / Line 9: @@
 The MIT Kerberos code base already include a KEYRING ccache type that uses kernel keyrings to implement a credential cache modeled after the FILE cache type.
 This cache type has 3 important limitations:
-* Uses only session or process or thread based keyrings
+* It uses only session, process, or thread based keyrings.  This means the cache cannot survive a user logout and cannot be shared between different sessions of the same user.
-This means the cache cannot survive a user logout and cannot be shared between different sessions of the same user.
+* It uses the classic "user" key type.  The "user" key type is limited in size because it uses non-swappable memory, so it has issues storing large tickets (like those including MS-PAC authdata) due to strict default quotas on this type of key.
 * It cannot represent cache collections.
-== Current Keyring cache format ==
+== Current keyring cache format ==
-The current implementation creates a new keyring named after the residual and links it to the session/process/thread special keyrings.
+The current implementation creates a new keyring named after the residual and links it to either the session, process, or thread special keyrings.
 Example:
@@ Line 33: / Line 30: @@
      \_ ...
 == Linux Kernel improvements ==
-Addition of a new key type "big_key" that allows us to create keys
+Addition of a new key type "big_key" that allows us to create keys up to 1MiB in size, backed by internal kernel tmpfs, allowing the
-up to 1MiB in size, backed by internal kernel tmpfs, allowing the
+contents to be swapped out to disk (unlike most other keyrings, which remain in unswappable kernel memory).
 Proposed patches by David Howells with explanatory comments on the kernel krbcache keyring:
@@ Line 56: / Line 46: @@
 The current keyring ccache type accepts the following residual forms:
 * KEYRING:<name>
 * KEYRING:process:<name>
 * KEYRING:thread:<name>
-Where name is an arbitrary string.
+where <name> is an arbitrary string.  The first form implies the use of a session keyring.
-libkrb5 will now accept a new values for the ccache name:
+libkrb5 will now accept new forms for the residual string:
 * KEYRING:session:<name>
@@ Line 68: / Line 59: @@
 * KEYRING:persistent:<uidnumber>
-Also all the keyrings will now allow to create cache collections.
+All residual forms will support cache collections.
-Individual ccache are identified and displayed by appending the specific ccache keyring name to the main residual:
+Individual ccaches within the collection are identified and displayed by appending the specific ccache keyring name to the main residual.  For example:
-Example:
- KEYRING:persistent:123:krb_ccache_WE324ffdX
+  KEYRING:persistent:123:krb_ccache_WE324ffdX
-== New Credential Cache Collection schema ==
+== New credential cache collection schema ==
-All KEYRING types become collection enabled, the only difference between the various types is where the ccache keyrings are linked into.
+All KEYRING types become collection enabled.  The only difference between the various types is where the cache keyrings are linked into.
-Each credential cache in the collection has a name of the form: krb_ccache_XXXXXX where XXXXXX is a random string and the name of the currently active ccache is stored into a key named krb_ccache:primary
+Each credential cache in the collection has a name of the form "krb_ccache_XXXXXX", where XXXXXX is a unique string.  The name of the currently active ccache is stored into a key named "krb_ccache:primary".
-All ccache keyring are furthemore stored in a keyring named fater the <name> part of the residual for keyring ccache of thread,process,session,user types, while in the case of the persistent keyring a keyring named _krb is created under the persistent keyring. For backwards compatibility reason on runtime upgrade the classic session keyring type (the one identified by KWYRING:<name>) uses the <name> part of the residual for the first ccache, so all the other ccache reside directly in the session keyring alongside the first one.
+For the "thread", "process", "session", and "user" residual forms, the ccache keyring is stored in a keyring named with the <name> part of the residual and linked into the appropriate special keyring.  For the "persistent" form, the ccache keyring is named "_krb" and is linked to the persistent keyring.  For backwards compatibility, the classic session residual form (the one identified by KEYRING:<name>) uses the <name> part of the residual for the first cache, and the other caches in the collection reside directly in the session keyring alongside the first one.
-The format of a single ccache keyring is unchanged from the classic scheme.
+The format of a ccache keyring is unchanged from the classic scheme.
 Examples:

@@ Line 93: / Line 93: @@
 Examples:
-KRB5CCNAME=KEYRING:testccache
+* KRB5CCNAME=KEYRING:testccache
  session
   \_ testccache
@@ Line 103: / Line 103: @@
   \_ krb_ccache:primary (points to testccache at collection cration)
-KRB5CCNAME=KEYRING:user:testusercc
+* KRB5CCNAME=KEYRING:user:testusercc
  user
   \_ testusercc
@@ Line 114: / Line 114: @@
       \_ krb_ccache:primary (krb_ccache_12WEF43f2)
-KRB5CCNAME=KEYRING:persistent:123
+* KRB5CCNAME=KEYRING:persistent:123
  _persistent.123
   \_ _krb

@@ Line 16: / Line 16: @@
 The "user" keytype is limited in size because use kernel locked memory so it has issues storing large tickets (like those including a MS-PAC AD) due to strict default quotas on this type of key
 * It cannot represent cache collections.
 = DesignComponents =