Bug 1311539 - Support for kernel keyring
Support for kernel keyring
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mod_auth_kerb (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Web Stack Team
BaseOS QE - Apps
Depends On:
  Show dependency treegraph
Reported: 2016-02-24 07:29 EST by Ondrej
Modified: 2016-03-09 09:26 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-09 09:26:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ondrej 2016-02-24 07:29:40 EST
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 17:45:34 EST
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 03:44:57 EST
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 04:01:31 EST
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

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 14:05:14 EST
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 03:43:16 EST
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 04:48:12 EST
As per 1) I guess we speak about httpd-itk from the EPEL repo.
Comment 9 Simo Sorce 2016-02-26 14:36:56 EST
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 14:40:08 EST
(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 08:07:22 EST
Thanks Simo.
Please feel free to close this report.
I will give a try to auth_gssapi module instead.

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

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