Skip Menu |
 

From: ghudson@mit.edu
Subject: git commit

Add collection support for KEYRING ccache type

Augment the KEYRING ccache type to support collection semantics
similar to those of the DIR type. For keyrings with no anchor prefix,
maintain compatibility with old code by linking the initial primary
cache directly from the session keyring and naming it after the
collection.

See http://k5wiki.kerberos.org/wiki/Projects/Keyring_collection_cache
for more information. Adapted from a patch by simo@redhat.com.

https://github.com/krb5/krb5/commit/c1e8d03a6254e3ce86a71eed31e4c127e3324f9b
Author: Greg Hudson <ghudson@mit.edu>
Commit: c1e8d03a6254e3ce86a71eed31e4c127e3324f9b
Branch: master
src/lib/krb5/ccache/cc_keyring.c | 939 +++++++++++++++++++++++++++------
src/lib/krb5/error_tables/k5e1_err.et | 2 +
2 files changed, 792 insertions(+), 149 deletions(-)
From: ghudson@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 1.5KiB

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.

https://github.com/krb5/krb5/commit/7c69a0372db5b7ed670ef3099a97942ede7a4739
Author: Greg Hudson <ghudson@mit.edu>
Commit: 7c69a0372db5b7ed670ef3099a97942ede7a4739
Branch: master
src/aclocal.m4 | 10 ++
src/lib/krb5/ccache/cc_keyring.c | 164 +++++++++++++++++++++++++++------
src/lib/krb5/error_tables/k5e1_err.et | 1 +
3 files changed, 148 insertions(+), 27 deletions(-)
From: ghudson@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 1.2KiB

Conditionally test KEYRING ccache type

If the keyctl command is found and klist recognizes the KEYRING
credential cache type, then run several tests against keyring ccaches:
the collection test program in lib/krb5/ccache, the command-line
collection tests in tests/t_ccache.py, and some new tests to verify
legacy session cache behavior. Much of the Python code in t_ccache.py
is moved into a new function named "collection_test" so we can run it
once against a DIR collection and once against a KEYRING collection.

Also: fix a memory leak in the collection test program; add a test for
iteration when the default cache name is a subsidiary name; use a
process keyring ccache in t_cc.c to avoid leaving behind empty
collections in the session keyring after each test run.

Adapted from a patch by simo@redhat.com.

https://github.com/krb5/krb5/commit/5d03cb6b235f0ee0e30b34630f95f208d6acd3d0
Author: Greg Hudson <ghudson@mit.edu>
Commit: 5d03cb6b235f0ee0e30b34630f95f208d6acd3d0
Branch: master
src/lib/krb5/ccache/t_cc.c | 4 +-
src/lib/krb5/ccache/t_cccol.c | 10 +++
src/lib/krb5/ccache/t_cccol.py | 58 ++++++++++++++++++-
src/tests/t_ccache.py | 128 +++++++++++++++++++++++++++-------------
4 files changed, 156 insertions(+), 44 deletions(-)
These patches are not yet setting expiry times on cache keyrings, so
caches in the persistent user keyring will stick around forever. We are
still exploring the best way to make the cache expiry time reflect the
latest credential expiry time.