Difference between revisions of "Projects/Keyring collection cache"
m (→Possible integration in the current KEYRING cache type) |
(→Possible integration in the current KEYRING cache type) |
||
| Line 39: | Line 39: | ||
| − | == |
+ | == Augmenting the current KEYRING cache type == |
| ⚫ | |||
| + | The current keyring ccache type accepts the following residual forms: |
||
| − | (for example: when used in KRB5CCNAME). |
||
| + | KEYRING:<name> |
||
| + | KEYRING:process:<name> |
||
| + | KEYRING:thread:<name> |
||
| − | It will take the form: |
||
| + | Where name is an arbitrary string. |
||
| − | KEYRING:krbcache:$UID |
||
| + | The first type implies the use of a session keyring. |
||
| − | to represent a credential cache collection and |
||
| − | KEYRING:krbcache:$UID:krb_ccache_XXXXXXX |
||
| − | to represent a specific key within a cache collection. |
||
| ⚫ | |||
| ⚫ | |||
| − | In this keyring a key called krbcache:index will contain a 4 byte version number and the name of the current primary cache, just like the 'primary' file contains the name of the primary cache for the DIR cache type. |
||
| + | KEYRING:session:<name> |
||
| + | KEYRING:user:<name> |
||
| + | KEYRING:persistent:<uidnumber> |
||
| − | Each cache will be stored in a child keyring, the format used in this keyring is the same as used by the classic KEYRING cache types except that tickets will be store in keys of type "big_key" instead of using the "user" type. |
||
| + | Also all the keyrings will now allow to create cache collections. |
||
| + | |||
| + | The session and user keyrings use the session and user's keyrings. |
||
| ⚫ | |||
| + | It requires support from the kernel for this new type otherwise it will fallback to use a user type keyring. |
||
Revision as of 12:22, 20 August 2013
Contents
Scope
Implement a new Kernel based credential cache collection that uses the Keys API.
The new cahe type is a collection and is store in a per-user keyring avaialble to any user session and that can persist in the system until expiration time even in the absence of an active user session.
Background and previous work
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
This means the cache cannot survive a user logout and cannot be shared between different sessions of the same user.
- Uses the classic "user" key type
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
Linux Kernel improvements
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 contents to be swapped out to disk (unlike most other keyrings, which remain in unswappable kernel memory).
Creation of a new public interface, keyctl_get_krbcache(uid_t, key_serial_t id). This API allows the user (and certain privileged root processes such as rpc.gssd and GSS-Proxy) to access the keys for a particular UID. This keyring is not tied to a session (so it can outlive a user on the system if they need to perform actions while not logged in, such as cron scripts access to Secure NFS). The kernel keyring is created automatically on the first request if it does not yet exist.
Proposed patches by David Howells with explanatory comments on the kernel krbcache keyring: http://mailman.mit.edu/pipermail/krbdev/2013-August/011650.html
Augmenting the current KEYRING cache type
The current keyring ccache type accepts the following residual forms: KEYRING:<name> KEYRING:process:<name> KEYRING:thread:<name>
Where name is an arbitrary string. The first type implies the use of a session keyring.
libkrb5 will now accept a new values for the ccache name:
KEYRING:session:<name> KEYRING:user:<name> KEYRING:persistent:<uidnumber>
Also all the keyrings will now allow to create cache collections.
The session and user keyrings use the session and user's keyrings. The new persistent type 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 fallback to use a user type keyring.
