re: Problem with CIFS

re: Problem with CIFS

[Steve French (IBM LTC)]

> I was trying to use CIFS, but it failed to mount my samba shares
> whereas mounting a share of a Win2K PC worked.   <snip>
> In fs/cifs/cifssmb.c around 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)

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

Re: [linux-cifs-client] re: Problem with CIFS

[Jeremy Allison]

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.

Cheers,

	Jeremy.

Re: Problem with CIFS

[Steve French]

>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;
>        }

I think Samba is just missing the else clause in smbd/negprot.c(since
reply_common sets FLAGS2_EXTENDED_SECURITY otherwise). Something like:

        else {
                remove_from_common_flags2(FLAGS2_EXTENDED_SECURITY);
                SSVAL(outbuf,smb_flg2,(SVAL(outbuf,smb_flg2) &
			 (~FLAGS2_EXTENDED_SECURITY)));
        }

but in any case I have to workaround it in the Linux cifs client by
paying more attention to the capability bit than to the actual smb flag

Re: Problem with CIFS

[Jeremy Allison]

On Wed, Aug 18, 2004 at 09:36:21PM -0500, Steve French wrote:
> >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;
> >        }
> 
> I think Samba is just missing the else clause in smbd/negprot.c(since
> reply_common sets FLAGS2_EXTENDED_SECURITY otherwise). Something like:
> 
>         else {
>                 remove_from_common_flags2(FLAGS2_EXTENDED_SECURITY);
>                 SSVAL(outbuf,smb_flg2,(SVAL(outbuf,smb_flg2) &
> 			 (~FLAGS2_EXTENDED_SECURITY)));
>         }
> 
> but in any case I have to workaround it in the Linux cifs client by
> paying more attention to the capability bit than to the actual smb flag

FYI: I just fixed this in the 3.x SVN tree. It won't be in 3.0.6
but should be in 3.0.7 and above. Thanks !

Jeremy.

Problem with CIFS

[Daniel Paschka]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

I was trying to use CIFS, but it failed to mount my samba shares whereas 
mounting a share of a Win2K PC worked.

I dowloaded and compiled the newest samba-server, but that didn't help 
either so I investigated a bit.

After googling if someone else was experiencing this problem I became a 
bit iritated because I only found a handful results, none helped to 
solve this problem in any way.

So I narrowed the problem down myself.

In fs/cifs/cifssmb.c around 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.

I am not sure what the right behaviour is (must cifs accept shorter 
seqenzes or must samba send some dummy bytes to fill up to 16 Bytes), 
but I think it should be possible to mount shares in workgroups which 
names are shorter the 4 Bytes.

Help would be appreciated
Daniel

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]