[linux-cifs-client] Kerberos5 support in cifs pathset [PATCH: 3/4] upcall handling via KEYS API for getting security blob and session key

[Jeff Layton]

On Thu, 25 Oct 2007 16:59:00 +0400
"Q (Igor Mammedov)" <qwerty0987654321 at mail.ru> wrote:

> Jeff Layton wrote:
> > 
> > I took the approach of passing around a key pointer to avoid some of
> > the copying, but I do the upcall in CIFSSMBNegotiate instead of
> > during CIFS_SessSetup.
> 
> Passing pointer is fine as far as data copied form key storage so
> that key could be destroyed and key description could be reused for
> the next possible negotiation steps.
> 

Yep. Currently my patchset just does a key_put at the end of
cifs_setup_session, but that can be changed if it's better to do it
another way.

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

> 
> 
> >> +			} else
> >> +				ascii_ssetup_strings(&bcc_ptr,
> >> ses, nls_cp);
> > 
> > Interesting. Is this correct? If unicode isn't enabled can we just
> > call ascii_ssetup_strings here? I've actually not seen any
> > non-unicode kerberos setups in the wild. Is it even possible?
> 
> Probably not, but just in case it happens ...
> 
> 

Ok, I wasn't sure. For now that's probably reasonable, but it wouldn't
surprise me if we had to break up ascii_ssetup_strings like we've done
for the unicode equivalent recently.


-- 
Jeff Layton <jlayton at redhat.com>