Bug 991110 - RFE: Add new kernel key type and per-UID persistent keyring for Kerberos support
Summary: RFE: Add new kernel key type and per-UID persistent keyring for Kerberos support
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.0
Hardware: All
OS: Linux
high
urgent
Target Milestone: beta
: ---
Assignee: Herton R. Krzesinski
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard: FailedQA
Depends On:
Blocks: 991148 991169 991184 991185 991186 1005422 1014739 1029110
TreeView+ depends on / blocked
 
Reported: 2013-08-01 16:44 UTC by Stephen Gallagher
Modified: 2019-09-05 17:36 UTC (History)
18 users (show)

Fixed In Version: kernel-3.10.0-44.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:00:23 UTC


Attachments (Terms of Use)

Description Stephen Gallagher 2013-08-01 16:44:37 UTC
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):
keyutils-1.5.5-4.el7

Comment 2 Ray Strode [halfline] 2013-08-01 18:40:15 UTC
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.

Comment 5 Colin Walters 2013-09-06 15:08:30 UTC
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.

Comment 6 Nalin Dahyabhai 2013-09-10 16:10:26 UTC
In terms of merging strategy, which Fedora releases is this being targeted for?

Comment 7 Paul W. Frields 2013-09-10 21:52:49 UTC
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.) ;-)

Comment 8 Stephen Gallagher 2013-09-12 13:41:05 UTC
@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.

Comment 13 Ray Strode [halfline] 2013-11-04 17:17:21 UTC
Do the patches in the bug include a notification API? (re comment 2)

Comment 14 Dmitri Pal 2013-11-04 23:19:23 UTC
(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.

Comment 15 Dmitri Pal 2013-11-04 23:21:17 UTC
(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
> releases.

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.

Comment 16 Ray Strode [halfline] 2013-11-05 14:46:59 UTC
bug 991184 is the kerb notification app bug.  Is there a bug for the deferred kernel pieces?

Comment 18 Jarod Wilson 2013-11-06 14:58:53 UTC
Patch(es) available on kernel-3.10.0-42.el7

Comment 22 Jarod Wilson 2013-11-07 22:11:14 UTC
Patch(es) available on kernel-3.10.0-44.el7

Comment 30 Linqing Lu 2014-04-23 04:32:54 UTC
Verified with kernel-3.10.0-121 following comment 17:

$ keyctl get_persistent @p
425414281
$ keyctl get_persistent @p `id -u`
425414281
$ keyctl get_persistent @p 0
keyctl_get_persistent: Operation not permitted

# keyctl get_persistent @p
915649207
# keyctl get_persistent @p `id -u`
915649207
# keyctl get_persistent @p 0
915649207

Comment 31 Linqing Lu 2014-04-23 05:59:28 UTC
Verified same results on x86_64, ppc64 and s390x.

Comment 32 Ludek Smid 2014-06-13 11:00:23 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.