]> git.ipfire.org Git - thirdparty/krb5.git/commit
Support new KEYRING anchor names and big_key keys
authorGreg Hudson <ghudson@mit.edu>
Sat, 28 Sep 2013 18:12:58 +0000 (14:12 -0400)
committerGreg Hudson <ghudson@mit.edu>
Wed, 2 Oct 2013 14:41:34 +0000 (10:41 -0400)
commit7c69a0372db5b7ed670ef3099a97942ede7a4739
treeb6561c3c5e5675fad5617e5795b9654a3e3f5cba
parentc1e8d03a6254e3ce86a71eed31e4c127e3324f9b
Support new KEYRING anchor names and big_key keys

Add support for the new anchor names persistent, user, and session.
The persistent anchor attempts to use a persistent keyring for a
specified uid, and falls back to the user keyring if it cannot; the
collection is stored at a fixed name within the persistent or user
keyring.  The session anchor uses the session keyring without legacy
semantics.

For all keyring types except legacy, attempt to use the "big_key" key
type on systems which have keyctl_get_persistent.  (They are
essentially unrelated features, but were added at the same time.)
This key type is stored in a kernel tmpfs and can store larger
tickets.

Since kernel commit 96b5c8fea6c0861621051290d705ec2e971963f1, new keys
created by add_key() only have VIEW permission for the user, and the
rest of the permissions require "possession," which means there is a
path from the thread, process, or session keyring to the key.  For the
user and persistent anchor types, we link the collection into the
process keyring to ensure that we have a possession rights on the
collection.

Adapted from a patch by simo@redhat.com.

ticket: 7711
src/aclocal.m4
src/lib/krb5/ccache/cc_keyring.c
src/lib/krb5/error_tables/k5e1_err.et