Re: cifs.ko and gssproxy

[Jacob Shivers <jshivers@redhat.com>]

Hi Steve,

On Fri, Dec 4, 2020 at 1:09 AM Steve French <smfrench@gmail.com> wrote:
>
> I see a brief mention of gssproxy by Jeff Layton more than three years
> ago, but don't remember any follow up on that.   What would be your
> goal in doing this?
>
> Presumably we could improve cifs.ko's ability to automatically
> autonegotiate new SMB sessions for incoming VFS requests from uids
> that have associated kerberos tickets.  Fortunately here is little

This and allowing for the use of unattended accounts to access
Kerberized SMB resources in much the same way they can like with NFS
shares.
For users in a mixed protocol environment they could grant some uid,
like for a database process, access to said Kerberized SMB share using
the same method they already deploy for NFS assuming gssproxy is
already in use.

> dependency on SPNEGO in cifs.ko (so it could be fairly easy to add
> other upcalls for SPNEGO), just during SMB3 session setup (and also in
> parsing the SMB3 negotiate response).   My bigger worry with handling
> SPNEGO (RFC2478) in the longer term, is adding support for the various
> other mechanisms (other than Kerberos and NTLMSSP) that servers can
> negotiate (PKU2U for example, and also the 'peer to peer kerberos'
> that Macs can apparently negotiate with SMB3 and SPNEGO).
> Authentication is mostly opaque to the SMB3 protocol, so if additional
> mechanisms can be negotiated  (transparently, with little impact on
> other parts of the kernel code) with SPNEGO in the future that would
> be of value

Ideally gssapi would be to allow for the transparent use of other
mechanisms and not be a blocker for deployment.