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
Branch: refs/heads/main
Home: https://github.com/gssapi/gssproxy
Commit: daaa2334d02553d136e10bf5b3a1a1ddd23eefd4
https://github.com/gssapi/gssproxy/commit/daaa2334d02553d136e10bf5b3a1a1ddd…
Author: Scott Mayhew <smayhew(a)redhat.com>
Date: 2021-09-03 (Fri, 03 Sep 2021)
Changed paths:
M src/gp_config.c
Log Message:
-----------
Call gp_debug_toggle() sooner
Currently gp_debug_toggle() is called at the end of load_config(), and
as a result any GPDEBUG() calls that happen during config processing are
no-ops.
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Commit: c6847f012b326a7e27dbe79d8df0faafdeb2dbef
https://github.com/gssapi/gssproxy/commit/c6847f012b326a7e27dbe79d8df0faafd…
Author: Scott Mayhew <smayhew(a)redhat.com>
Date: 2021-09-03 (Fri, 03 Sep 2021)
Changed paths:
M examples/99-nfs-client.conf.in
M man/gssproxy.conf.5.xml
M src/gp_config.c
M src/gp_creds.c
M src/gp_proxy.h
Log Message:
-----------
Add an option for minimum lifetime
It's possible for gssproxy to return a cached credential with a very
small remaining lifetime. This can be problematic for NFS clients since
it requires a round trip to the NFS server to establish a GSS context.
Add a min_lifetime option that represents the lowest value that the
lifetime of the cached credential can be. Any lower than that, and
gp_check_cred() returns GSS_S_CREDENTIALS_EXPIRED, so that
gp_add_krb5_creds() is forced to try to obtain a new credential.
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Compare: https://github.com/gssapi/gssproxy/compare/00bcb2dd4fe2...c6847f012b32