Bug 1497267 - gssproxy mechglue running in the rpc.gssd context, clobbers the root user's ccache [NEEDINFO]
Summary: gssproxy mechglue running in the rpc.gssd context, clobbers the root user's c...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gssproxy (Show other bugs)
(Show other bugs)
Version: 7.4
Hardware: All All
high
high
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: ipa-qe
URL: https://pagure.io/gssproxy/pull-reque...
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-29 15:33 UTC by aheverle
Modified: 2018-08-02 19:18 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-08-02 19:18:39 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rharwood: needinfo? (aheverle)


Attachments (Terms of Use)

Description aheverle 2017-09-29 15:33:34 UTC
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 17:48:48 UTC
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 18:18:01 UTC
(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 18:58:22 UTC
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 19:30:34 UTC
Please clone to fedora too

Comment 28 Simo Sorce 2017-11-16 19:37:17 UTC
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 19:52:44 UTC
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 16:32:42 UTC
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 13:21:43 UTC
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.


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