Problem with CIFS
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines
I was trying to use CIFS, but it failed to mount my samba shares
whereas mounting a share of a Win2K PC worked. <snip>
Infs/cifs/cifssmb.caround line 238 the cifs modul expects a 16 Byte GUID, where samba only send 14 bytes consisting of some random numbers followed by my workgroupname: WG.
So I to set my workgroupname to something longer with enabled me to mount my share.
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). Presumably all
other smb/cifs clients either 1) negotiate extended security (this is turned off by default in the cifs vfs ie /proc/fs/cifs/ExtendedSecurity is zero) or 2) don't check or don't care what is in the bcc area of the negprot response (which is the case for earlier clients)
Quoted 2 lines
but I think it should be possible to mount shares in workgroups which names are shorter the 4 Bytes.
Yes you are correct - there is no minimum domain length, although there is a minimal bcc length for true NTLMSSP and SPNEGO negotiate responses which I will now be
forced to detect differently on the client. As you noticed it worked for longer
domain names, because the bcc was larger and spnego decoding was harmless for longer domain names.
I will fix this today, probably by adding a check in fs/cifs/cifssmb.c (in CIFSSMBNegotiate) in parsing the negotiate response from something like from:
if (pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC)
to
if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC) &&
(server->capabilities & CAP_EXTENDED_SECURITY))
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.
Quoted 13 lines · Steve French (IBM LTC)
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 thisSMB_FLAGS2_EXTENDED_SECURITYin the response even though the client said - no extended security (Windows gets this right).
....
The Samba fix is pretty easy as well (it only hitssource/smbd/negprot.c-reply_negprotfunction), 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.
Cheers,
Jeremy.