generally I would feel more comfortable using something (library or
utility) in Samba (if needed) for additional SPNEGO support if
something is missing (in what the kernel drivers are doing to
encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as
Samba is better maintained/tested etc. than most components. Is there
something in Samba that could be used here instead of having a
dependency on another project - Samba has been doing Kerberos/SPNEGO
longer than most ...? There are probably others (jra, Metze etc.)
that have would know more about gssproxy vs. Samba equivalents though
and would defer to them ...
On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce <simo(a)redhat.com> wrote:
as you say the best course of action would be for cifs.ko to move to
use the RPC interface we defined for knfsd (with any extensions that
may be needed), and we had discussions in the past with cifs upstream
developers about it. But nothing really materialized.
If something is needed in the short term, I thjink the quickest course
of action is indeed to change the userspace helper to use gssapi
function calls, so that they can be intercepted like we do for rpc.gssd
(nfs client's userspace helper).
Unfortunately I do not have the cycles to work on that myself at this
On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:
> 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.
> 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.
> From what I understand, the preferred method would be to switch the Linux kernel
client upcall to the RPC protocol defined by gssproxy (as has been done for the Linux
kernel NFS server already replacing rpc.svcgssd). 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).
> 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
> I have found a recent discussion of the topic on linux-cifs 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
> Is this something that could be implemented without too much redundant effort (or
should already work, perhaps using a different tool)?
>  https://pagure.io/gssproxy/issue/56
>  https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md
>  https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server
>  https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client
>  https://www.spinics.net/lists/linux-cifs/msg20182.html
> gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
> To unsubscribe send an email to gss-proxy-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
RHEL Crypto Team
Red Hat, Inc