[linux-cifs-client] Re: [PATCH] [CIFS] clean legacy cruft out of connect.c

[Jeff Layton]

On Wed, 7 May 2008 13:57:52 -0500
"Steve French" <smfrench at gmail.com> wrote:

> On Wed, May 7, 2008 at 1:35 PM, Jeff Layton <jlayton at redhat.com> wrote:
> > cifs_setup_session has a lot of legacy cruft. In practice these days,
> >  "experimEnabled" is generally always less than 2. Session setup is
> >  pretty much always handled by CIFS_SessSetup. This patch eliminates
> >  the unused code in that function and does some cleanup to reduce the
> >  amount of indentation. It also removes 3 session setup functions that
> >  are now handled by CIFS_SessSetup.
> >
> >  I know there was some concern that there was some logic in this code to
> >  which we wanted to be able to refer later. Anyone needing to do that
> >  though can always just pull up an old git tree, so there's not much
> >  reason to keep the current code cluttered up with it.
> >
> >  Signed-off-by: Jeff Layton <jlayton at redhat.com>
> 
> The main thing I wanted to double check before removal is whether
> NTLMSSP enablement works without switching this old code back on or
> whether there are any legacy LANMAN cases which require any of these
> old disabled-by-default routines.
> 

As best I can tell, NTLMSSP will not work at all if we remove this
code....but, I'm not convinced that it currently works anyway. In
CIFSSMBNegotiate, we do this:

        if ((secFlags & CIFSSEC_MUST_KRB5) == CIFSSEC_MUST_KRB5)
                pSMB->hdr.Flags2 |= SMBFLG2_EXT_SEC;
        else if ((secFlags & CIFSSEC_AUTH_MASK) == CIFSSEC_MAY_KRB5) {
                cFYI(1, ("Kerberos only mechanism, enable extended security"));
                pSMB->hdr.Flags2 |= SMBFLG2_EXT_SEC;
        }

...so we only request extended security negotiation iff we're forcing
kerberos auth. I don't think we can do NTLMSSP unless we turn on that
flag, can we?

I'm still not sure about the legacy LANMAN stuff. I haven't heard of
anyone needing to crank up experimEnabled to make that work, but that
doesn't mean they don't exist. If you can let me know of any servers
you're concerned about, I can try to have a look at them.

Cheers,
-- 
Jeff Layton <jlayton at redhat.com>