[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-cifs-client
Subject:    Re: [linux-cifs-client] Kerberos5 support in cifs pathset [PATCH:
From:       "Q (Igor Mammedov)" <qwerty0987654321 () mail ! ru>
Date:       2007-10-30 16:12:21
Message-ID: 472757E5.3010008 () mail ! ru
[Download RAW message or body]

Jeff Layton wrote:
> On Thu, 25 Oct 2007 16:59:00 +0400 "Q (Igor Mammedov)"
> <qwerty0987654321@mail.ru> wrote:
> 
>> Jeff Layton wrote: As for CIFSSMBNegotiate vs CIFS_SessSetup I
>> thought that in case of multi-stage negotiation we would have to do
>> upcalls in CIFS_SessSetup too. That's why I've did it
>> CIFS_SessSetup.
>> 
> 
> True. I think with the design I have, we can easily do it from either
>  place (or even both). The advantage of doing it in CIFSSMBNegotiate
> is that we can have userspace do all of the SPNEGO parsing and tell
> the kernel the secType. I suppose we could do that in CIFS_SessSetup
> too but it means a bigger change there.

SecBlob from response message in CIFSSMBNegotiate just provide us with 
supported MECHs and if we use MS-KRB5 then we can use MIC from it.
We already have simple in kernel asn1 parsing code that does exactly
this thing ( determines what secType to use based on mount sec option 
and server supported MECHs in decode_negTokenInit ).
And we could stop right here if server doesn't support requested sec option.

IMHO, Doing SPNEGO upcall in CIFS_SessSetup where it take place by 
protocol (SMB_COM_SESSION_SETUP_ANDX) looks less confusing rather than 
doing it in CIFSSMBNegotiate where SecBlob is just a hint but not a part 
of SPNEGO conversation.

-- 

Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com




_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
[prev in list] [next in list] [prev in thread] [next in thread]