[linux-cifs-client] Kerberos5 support in cifs pathset [PATCH: 2/4] enables extended security in NEG... and SESSION_SETUP... requests when mounting with krb5i option

[Jeff Layton]

On Tue, 30 Oct 2007 18:22:14 +0300
"Q (Igor Mammedov)" <qwerty0987654321 at mail.ru> wrote:

> Jeff Layton wrote:
> >> Jeff Layton wrote:
> >> Simple pre parsing not only helps to decide whether do upcall or
> >> not, but can help to
> >> determine if negotiation has been accepted by server or we need
> >> continue negotiation.
> > 
> > I'd think that we can probably determine success or failure by the
> > actual return code from the NegotiateProtocol reply itself. If it
> > fails with certain return codes (maybe
> > NT_STATUS_MORE_PROCESSING_REQUIRED?), then we'll know to hand the
> > blob back to userspace and continue the negotiation.
> 
>  From what I've seen server often returns 
> NT_STATUS_MORE_PROCESSING_REQUIRED when secblob is invalid so we cant 
> use it for this purpose.
> 
> 

My thought was that if we get a STATUS_SUCCESS return code from the
server then we'll know that things have been accepted. If not (and the
error's not something obvious like -EHOSTDOWN), then we'd know to
upcall again. The userspace program would then have to interpret the
blob and let us know what the actual status is (accept-reject,
accept-incomplete, etc).

The problem is that no one seems to know what an actual multi-stage
negotiation is going to look like in practice. We don't know what
the SMB return code will actually be in this situation. I suppose it
could even be STATUS_SUCCESS, which would mean that we'd always need to
upcall with the reply.


-- 
Jeff Layton <jlayton at redhat.com>