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.

(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?

nothing really, it always did that afaik, I think a new behavior in gssproxy may have made it show up more though.

Please clone to fedora too

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 ...)

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 :/

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."

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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days