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 1311539 - Support for kernel keyring
Summary: Support for kernel keyring
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mod_auth_kerb
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Luboš Uhliarik
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-24 12:29 UTC by Ondrej
Modified: 2021-01-14 09:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-09 14:26:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ondrej 2016-02-24 12:29:40 UTC
Description of problem:
RHEL-7 stores user tickets by default in Kernel keyring.
mod_auth_kerb should honor setting in /etc/krb5.conf and if keyring is specified, it should store user Kerberos cache in keyring.

Use case: We need Kerberos cache to authenticate NFS access, however rpc.gssd takes user principals from kernel keyring. Mod_auth_kerb store them in /run -> rpc.gssd is unable to find them -> access to Kerberized NFS share is refused -> Apache is unable to serve web pages.

Comment 3 Simo Sorce 2016-02-24 22:45:34 UTC
you should probably use mod_auth_gssapi, however neither will generate ccaches that rpc.gssd can use out of the box as both only store ccaches a the apache user and rpc.gssd looks up ccaches and then check that the uid matches that of the user making a request.

If the apache user is making the request then storing creds would work, but I question the utility of such a setup given that any user connecting to apache would cause such credentials to be replaced *yet* the actual nfs connection will be the original one established with the first set of credentials as the kernel has no connection with user space and does not know when credentials are removed/destroyed.

What is the actually desired access pattern ?

Comment 4 Ondrej 2016-02-25 08:44:57 UTC
My desired access pattern:
I want to access a web page (or even run a CGI/PHP script) in a project directory shared via NFS.
Due to the security restrictions, "apache" user can not access that directory - only the project owner + members of the project team.

There is no way (at least known to me) to make Apache spawn a helper process running under authenticated user privileges (suexec only works for CGI, not for plain html static pages)

So my only chance is to replace NFS/AUTH_SYS with NFS/AUTH_GSSAPI. This way, the user accessing the NFS share does not actually matter at all. What only matters is whose credentials you have in your ticket cache. So Apache authenticates a user, stores his credential in cache owned by user apache - so rpc.gssd is happy - NFS share is mounted, access granted, web page displayed. When done, apache destroys the cache - but I do not care as the request has already been handled successfully.

This is proven to work in RHEL-6. I want this to work in RHEL-7. too.

Comment 5 Ondrej 2016-02-25 09:01:31 UTC
There is only one other problem with this:
It seems to me that Apache checks for existence of the web page/directory BEFORE authenticating user. For example:
<Location /private>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate Off
  KrbSaveCredentials on
</Location>

now If I try to navigate to "https://myserver.com/private/myproject/mypage.html",I am not prompted for username/passwd - instead, I receive "Not found" page.

Currently I solve this problem using mod_proxy which points to ourselves - this blames Apache so it does not try to check for page existence.

As I say, the concept seems to me very nice (if it weren't for the hack with mod_proxy) and actually works.

Comment 6 Simo Sorce 2016-02-25 19:05:14 UTC
Do you care that any user can actually access the data after the first authentiation ?

The problem with your setup is that once user A gets access to the data, any following access is performed with user A filesystem credentials, regardless of what other user B, C or D authenticates, for as long as credentials were originally valid (10 hours in some setups, 24 hours in others).

You could have an apache process running as a specific user, and have mod_proxy redirect connections to that apache process using mod_proxy I guess.

Comment 7 Ondrej 2016-02-26 08:43:16 UTC
Hmm, it really works that way - I did not know, thanks for the warning.
So the (pseudo) solution would be to limit TGT lifetime in /etc/krb5.conf to say 10 minutes.

I have two additional questions then:
1. Is it really possible to make Apache to spawn a helper process running as a specific (authenticated) user? How? Does anyone know (I know it is OT, sorry)?

2. With mod_auth_gssapi I could have the similar setup I have now in RH-6 working in RHEL-7 as well, can you confirm?

Many thanks.

Comment 8 Ondrej 2016-02-26 09:48:12 UTC
As per 1) I guess we speak about httpd-itk from the EPEL repo.

Comment 9 Simo Sorce 2016-02-26 19:36:56 UTC
mod_auth_gssapi is meant to replace mod_auth_kerb going forward as mod_auth_kerb upstream has been dead for years and the code is crusty.

I am not sure that it will make any difference whichever you use given your state goals though, as neither has been built with your goal in mind.

However if there is a chance of getting new features that is by requesting them for mod_auth_gssapi, as we prefer not to put our hands (for new features) in the mod_auth_kerb code going forward.

Comment 10 Simo Sorce 2016-02-26 19:40:08 UTC
(In reply to Ondrej from comment #8)
> As per 1) I guess we speak about httpd-itk from the EPEL repo.

Afaik httpd-itk rquires a different vhost per user, I am not aware of a module that will fork and change uid/gid for a user as it gets access to the server the way you described it unfortunately.

Comment 11 Ondrej 2016-02-29 13:07:22 UTC
Thanks Simo.
Please feel free to close this report.
I will give a try to auth_gssapi module instead.

Ondrej

Comment 12 Joe Orton 2016-03-09 14:26:09 UTC
Thanks Simo!  I'm closing this out.


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