Overview of Linux kernel keyrings

    Linux keyrings are significantly more complicated than AFS PAGs in
    that they provide not only for per-session association of resources
    with processes, but also: per-user, per-process and per-thread.
    There are other major differences as well.

    The metaphor is: keyrings such as those people use to put real keys
    in.  One might carry multiple keyrings, with multiple keys in each
    keyring.  Keys attach to keyrings, and keyrings attach to keyrings.
    And one might search for a desired kind of key in the various
    keyrings in a particular order.

    The core interfaces of Linux keyrings are: keyctl(2), add_key(2),
    request_key(2), keyctl(1), and several utility library functions
    that map onto sub-codes of keyctl(2).

    Keyrings come in two flavors: a) a single, specially named keyring
    with thread-, process-, session- and user-affinity, b) named
    keyrings that are "attached" or "linked" to one of the keyrings
    mentioned in (a).

    Each named keyring can store a "key" which may or may not be a key
    in the cryptographic sense.  For example, the Linux secure NFS
    client stores Kerberos V credentials cache names as keys (compare to
    AFS which names Kerberos credentials cache after PAG IDs to obtain
    the same effect).

    Applications that need a "key" search the thread, process, session,
    user keyrings (in that order) for a named keyring where the name
    corresponds to the application.

    The kernel may upcall to user-land (in the form of creating a new
    process that exec()s /sbin/request-key) to obtain key data for keys
    that are not available in the triggering thread's keyrings.


REFERENCES
----------

    http://linux.die.net/man/1/keyctl
    http://linux.die.net/man/2/keyctl
    http://www.ibm.com/developerworks/linux/library/l-key-retention.html
    http://mailman.mit.edu/pipermail/krbdev/2005-April/003311.html