Description of problem:
In order to address issues with file-based Kerberos credential caches, we should enhance the kernel keyring interface to support newer functionality. Based on discussions between Simo, Nalin, David and myself, we propose the following behavior:
1) We will add 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).
2) We will create a new public interface, keyctl_get_krbcache(uid_t, key_serial_t id). This API will allow the user (and certain privileged root processes such as rpc.gssd and gss-proxy) to access the keys for a particular UID. This keyring shall not be 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 access to secure NFS). The kernel keyring should be created automatically on the first request if it does not yet exist. It must also be possible to manipulate the lifetime timer with functions like keyctl_set_timeout() (to align the keyring life with the credential validity) and must also be possible to be destroyed immediately using the usual keyctl APIs (such as in the kdestroy case).
Version-Release number of selected component (if applicable):
as part of 2), we really need some sort of change notification api as well so things like gnome-online-accounts can monitor the cache for changes.
What about something like "usertmpfs" which would polyinstantiate per uid? Then userspace could mount it at /run/user.
What we avoid with this model is having to run the PAM stack just to have systemd mkdir("/run/user/X"). Instead, if a process with a given uid exists, that's enough to cause the directory to be auto-mounted effectively (if the process accesses the tmpdir).
Having "big" data in the kernel keyring is yet another place that userspace processes can accumulate data in a way not easily visible to administrators.
Notifications are just inotify, etc.
In terms of merging strategy, which Fedora releases is this being targeted for?
Note, since RHEL 7.0 branched already and isn't automatically pulling from any Fedora releases any longer, needs to be merged with care. (Sorry if this is obvious, not everyone reads the RHEL 7 schedule stuff.) ;-)
@Nalin: If the Kernel team is willing to backport the new persistent keyring patches to F19, then we'll support F19. If not, it will be Fedora 20+
@Colin: We tried that approach, but we couldn't make it work with OpenSSH and a few other situations because they do the credential acquisition as a different user than the one that is logging in, so there's no guarantee that usertmpfs will have created the directory. There's also a race-condition inherent there.
The patches required for this are upstream as far as the linux-security tree and are awaiting the next merge window:
Do the patches in the bug include a notification API? (re comment 2)
(In reply to Ray Strode [halfline] from comment #13)
> Do the patches in the bug include a notification API? (re comment 2)
I do not think so. All cred cache monitoring thing was deferred till later releases.
(In reply to Dmitri Pal from comment #14)
> (In reply to Ray Strode [halfline] from comment #13)
> > Do the patches in the bug include a notification API? (re comment 2)
> I do not think so. All cred cache monitoring thing was deferred till later
This means that the kerb notification app would continue to poll for ticket status. I should look at a different cache location/type though.
Have there been a bug about that? I thought there was.
bug 991184 is the kerb notification app bug. Is there a bug for the deferred kernel pieces?
Patch(es) available on kernel-3.10.0-42.el7
Patch(es) available on kernel-3.10.0-44.el7
Verified with kernel-3.10.0-121 following comment 17:
$ keyctl get_persistent @p
$ keyctl get_persistent @p `id -u`
$ keyctl get_persistent @p 0
keyctl_get_persistent: Operation not permitted
# keyctl get_persistent @p
# keyctl get_persistent @p `id -u`
# keyctl get_persistent @p 0
Verified same results on x86_64, ppc64 and s390x.
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.