Hello,
I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].
My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]
From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.
Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).
Assuming my understanding is correct so far:
Is anyone doing any work on this and could use some help (testing, coding)?
What would be expected complexity and possible roadblocks when trying to make a start at implementing this?
Or is the idea moot due to some constraint or recent development I'm not aware of?
I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.
As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on.
Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?
[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation…
[2] https://pagure.io/gssproxy/issue/56
[3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md
[4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server
[5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client
[6] https://www.spinics.net/lists/linux-cifs/msg20182.html
--
Thanks,
Michael
I've recently switched from using k5start to gssproxy to allow my users to access NFSv4 mounts with sec=krb5, using keytabs I manage for them. I have just one service configured in gssproxy:
[service/nfs-client]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
cred_store = client_keytab:/var/local/keytabs/%u.keytab
cred_usage = initiate
allow_any_uid = yes
trusted = yes
euid = 0
I thought everything was working great, but now I find that I can't mount remote filesystems when gssproxy is running. If I stop gssproxy, mount works. If I change sec=krb5 to sec=sys, mount works. It seems clear that gssproxy is preventing mount from working. When I run mount -a, I get errors like this:
mount.nfs: access denied by server while mounting [...]
When I add -vvv to rpc.gssd, this is what I see in syslog (anonymized):
rpc.gssd[6512]: WARNING: Machine cache prematurely expired or corrupted trying to recreate cache for server nfs.example.com
rpc.gssd[6512]: Full hostname for 'nfs.example.com' is 'nfs.example.com'
rpc.gssd[6512]: Full hostname for 'client.zz.example.com' is 'client.zz.example.com'
rpc.gssd[6512]: No key table entry found for client$(a)AD.EXAMPLE.COM while getting keytab entry for 'client$(a)AD.EXAMPLE.COM'
rpc.gssd[6512]: Success getting keytab entry for 'CLIENT$(a)AD.EXAMPLE.COM'
rpc.gssd[6512]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_AD.EXAMPLE.COM' are good until 1624541464
rpc.gssd[6512]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_AD.EXAMPLE.COM' are good until 1624541464
rpc.gssd[6512]: creating tcp client for server nfs.example.com
rpc.gssd[6512]: DEBUG: port already set to 2049
rpc.gssd[6512]: creating context with server nfs(a)nfs.example.com
rpc.gssd[6512]: WARNING: Failed to create krb5 context for user with uid 0 for server nfs(a)nfs.example.com
rpc.gssd[6512]: WARNING: Failed to create machine krb5 context with cred cache FILE:/tmp/krb5ccmachine_AD.EXAMPLE.COM for server nfs.example.com
rpc.gssd[6512]: ERROR: Failed to create machine krb5 context with any credentials cache for server nfs.example.com
rpc.gssd[6512]: doing error downcall
I'm running version 0.8.0, as distributed with Debian Buster (I worked around the systemd ordering cycle bug in that version by using the upstream unit file). The fileserver is run by a different group and kerberos is AD.
Googling for answers, I found others describe similar problems, but no solutions that make sense to me. Help!
John
