RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 2023-08-08 02:39 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
Target Upstream Version:
Embargoed:

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 10 David Howells 2013-10-02 16:25:50 UTC 
The patches required for this are upstream as far as the linux-security tree and are awaiting the next merge window:

http://git.kernel.org/cgit/linux/kernel/git/jmorris/linux-security.git/commit/?h=next&id=ab3c3587f8cda9083209a61dbe3a4407d3cada10
http://git.kernel.org/cgit/linux/kernel/git/jmorris/linux-security.git/commit/?h=next&id=f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e
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.