[lkml]   [2004]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-cifs-client] re: Problem with CIFS
On Thu, Aug 19, 2004 at 05:09:04AM -0500, Steve French (IBM LTC) wrote:
> This is caused by an interesting bug in Samba, but one I should be able to
> workaround. Basically Samba is setting a flag in the negotiate response saying
> "I support extended security"
> which indicates that this frame should be decoded as if it contained an SPNEGO blob
> (ala RFC 2478) and a conflicting capability in the same frame which indicates
> "I am not capable of extended security"
> The Samba server sets this SMB_FLAGS2_EXTENDED_SECURITY in the response even though
> the client said - no extended security (Windows gets this right).
> ....
> The Samba fix is pretty easy as well (it only hits source/smbd/negprot.c -
> reply_negprot function), I will bounce the fix off jra before updating the Samba 3
> source.

Can you show me where the problem is ? Currently in smbd/negprot.c we have :

/* do spnego in user level security if the client
supports it and we can do encrypted passwords */

if (global_encrypted_passwords_negotiated &&
(lp_security() != SEC_SHARE) &&
lp_use_spnego() &&
(SVAL(inbuf, smb_flg2) & FLAGS2_EXTENDED_SECURITY)) {
negotiate_spnego = True;
capabilities |= CAP_EXTENDED_SECURITY;

Which I thought should be correct.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.017 / U:17.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site