Bug 1497267

Summary: gssproxy mechglue running in the rpc.gssd context, clobbers the root user's ccache
Product: Red Hat Enterprise Linux 7 Reporter: aheverle
Component: gssproxyAssignee: Robbie Harwood <rharwood>
Status: ASSIGNED --- QA Contact: ipa-qe <ipa-qe>
Severity: high Docs Contact:
Priority: high    
Version: 7.4CC: aheverle, amessina, fs-qe, gparente, hkhot, jiyin, jvilicic, lnykryn, pasik, rharwood, rmj, ssorce, tscherf, yoyang
Target Milestone: rcFlags: rharwood: needinfo? (aheverle)
Target Release: ---   
Hardware: All   
OS: All   
URL: https://pagure.io/gssproxy/pull-request/216
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description aheverle 2017-09-29 11:33:34 EDT
Description of problem:
Moments after obtaining a TGT, it disappears from the system.

Version-Release number of selected component (if applicable):
gssproxy-0.4.1-13.el7.x86_64

How reproducible:
Everytime

Steps to Reproduce:
1. kinit admin
2. klist
3. klist

Actual results:
TGT is no longer there

Expected results:
TGT is no longer there
Comment 24 Simo Sorce 2017-11-16 12:48:48 EST
This is ultimately an rpc.gssd issue.
rpc.gssd is running as root but it is not setting a custom ccache.
So it ends up clobbering root's ccaches whenever it needs machine credentials.

rpc.gssd needs to be given an env var argument so that it uses a different ccache by default.
It is OK to make it use a FILE ccache as it doesn't need anything fancy, however it should store the cache prefereably under /run in a custom rpc.gssd directory.

/etc/sysconfig.nfs should have a new variable like this:
KRB5CCNAME=FILE:/run/rcp.gssd/machine_ccache

And the nfs package should add a systemd tmpfiles configuration to create /run/rpc.gssd at boot with permissions 0700


Steve, let me know if anything is unclear.
Comment 25 Steve Dickson 2017-11-16 13:18:01 EST
(In reply to Simo Sorce from comment #24)
> This is ultimately an rpc.gssd issue.
> rpc.gssd is running as root but it is not setting a custom ccache.
> So it ends up clobbering root's ccaches whenever it needs machine
> credentials.
> 
> rpc.gssd needs to be given an env var argument so that it uses a different
> ccache by default.
> It is OK to make it use a FILE ccache as it doesn't need anything fancy,
> however it should store the cache prefereably under /run in a custom
> rpc.gssd directory.
> 
> /etc/sysconfig.nfs should have a new variable like this:
> KRB5CCNAME=FILE:/run/rcp.gssd/machine_ccache
> 
> And the nfs package should add a systemd tmpfiles configuration to create
> /run/rpc.gssd at boot with permissions 0700
> 
> 
> Steve, let me know if anything is unclear.

What has changed where rpcgssd needs to set the ccache?
Comment 26 Simo Sorce 2017-11-16 13:58:22 EST
nothing really, it always did that afaik, I think a new behavior in gssproxy may have made it show up more though.
Comment 27 Simo Sorce 2017-11-16 14:30:34 EST
Please clone to fedora too
Comment 28 Simo Sorce 2017-11-16 14:37:17 EST
Note that nfs-utils_env.sh is quite limited and doesn;t just copy all env vars from /etc/sysconfig/nfs, but only the ones it knows about, this is very suboptimal and should be changed as well, it makes little sense to have to hack unit files just to add environment variables. the env util should copy them all (or we should stop using this env util and directly point at /etc/sysconfig/nfs ...)
Comment 29 Simo Sorce 2017-11-16 14:52:44 EST
Steve,
btw please sync with me before doing this, there may be an interaction with the new way rpc.gssd used threads setting fsuid that may cause issues finding uses ccaches via gssapi if we set a variable :/
Comment 36 Anthony Messina 2017-11-19 11:32:42 EST
Simo, just FYI...

In my limited testing, creating a separate keytab for rpc.gssd does allow a machine to mount a sec=krb5 mount, but gssproxy still fails to get the TGT for a non-root user/client using gssproxy to access the contents within the mount.

My simple scenario is a non-root user "mythtv" with a keytab stored in /var/lib/gssproxy/clients/<mythtv-uid>.keytab which had been using gssproxy in F26 to access a sec=krb5i mount upon systemd.automount.  While the machine correctly mounts the filesystem, the "mythtv" user only gets permission denied.

This may be what you were referring to when you stated "there may be an interaction with the new way rpc.gssd used threads setting fsuid that may cause issues finding uses ccaches via gssapi if we set a variable."
Comment 37 Simo Sorce 2017-11-20 08:21:43 EST
Yes, if the variable is set then gssproxy impersonation will not work.
We are retiring that suggest as a viable workaround and working on an alternative solution.