cifs.ko and gssproxy

cifs.ko and gssproxy

[Jacob Shivers]

Hello all,

Is anyone working on modifying cifs.ko to work with gssproxy directly?

There were comments a few years ago about such an endeavor, but I have
not seen any further discussion in recent years.

Thanks for any information,
Jacob

Re: cifs.ko and gssproxy

[Steve French]

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

On Thu, Dec 3, 2020 at 4:08 PM Jacob Shivers <jshivers@redhat.com> wrote:
>
> Hello all,
>
> Is anyone working on modifying cifs.ko to work with gssproxy directly?
>
> There were comments a few years ago about such an endeavor, but I have
> not seen any further discussion in recent years.
>
> Thanks for any information,
> Jacob
>


-- 
Thanks,

Steve

Re: cifs.ko and gssproxy

[Jacob Shivers]

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.