kafs-client (recent strangeness of with add_key)

[Chaskiel Grundman]

On Sat, May 28, 2022 at 5:54 PM Spencer Olson <olsonse at umich.edu> wrote:
>
> In the last month or so, I've noticed that aklog-kafs has not been
> working properly all the time.  The library call to "add_key" does not
> always result in the afs tokens being stored in the session keyring.
> I think this is pretty strange.  There are no errors that I can find
> and nothing in the system log files that seem to indicate why the key
> does not actually get stored.

This is probably not due to a kernel change, but something in
userspace.  kafs's aklog, following AFS's example, tries to attach the
key to the session keyring, but it's less common these days for
processes to have a session keyring (instead they use the "(one per)
uid session" keyring in the session slot). If aklog is run from a
process without a session keyring, aklog will implicitly create a new
session keyring, attach its key to it, and then exit, orphaning the
new session. My proof of concept for krb5 kafs aklog has included a
workaround for this for a while (but it was probably not in the
original 2009 code). See
https://github.com/cg2v/kafs-tools/blob/master/aklog-kafs/aklog-kafs-kdf.c#L230-L239

You should not just switch from KEY_SPEC_SESSION_KEYRING to
KEY_SPEC_USER_SESSION_KEYRING, since that will cause aklog to fail
(and do the wrong thing) when the process does have a real session
keyring.
It may just work to substitute
keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0) for
KEY_SPEC_SESSION_KEYRING on the add_key line