One little patch for samba libsmb

[Shawn Pringle]

On 11/24/2013 11:38 PM, Andrew Bartlett wrote:
> On Sun, 2013-11-24 at 19:24 -0300, Shawn Pringle wrote:
>> On 11/24/2013 06:22 PM, Andrew Bartlett wrote:
>>> On Sat, 2013-11-23 at 12:20 -0300, Shawn Pringle wrote:
>>>> On 11/22/2013 01:20 AM, Andrew Bartlett wrote:
>>>>> On Thu, 2013-11-07 at 10:47 -0300, Shawn Pringle wrote:
>>>>>> I've found a bug in samba-3.6.8.  Some file names will be missing the
>>>>>> first letter when listing.  I traced the problem to a call to
>>>>>> align_string() in source3/libsmb/clilist.c.
>>>>>>
>>>>>> Now the issue seems to be some OSes align their strings on the two byte
>>>>>> boundary where as others do not.  To reproduce the bug you must have a
>>>>>> Windows 98 with long filenames in them and the strings allocated need to
>>>>>> happen to be located at an odd numbered address in memory.  With two
>>>>>> score file names you will likely see this problem occur.
>>>>>>
>>>>>> I am not sure whether cli->win95 is the correct condition to test for by
>>>>>> itself.  It is a starting point.
>>>>>>
>>>>>> 89c89,94
>>>>>> <             p += align_string(base_ptr, p, 0);
>>>>>> ---
>>>>>>>             /* The following align_string call would misalign the pointer
>>>>>>>              * to file names listed from a Windows 98 machine.*/  
>>>>>>>             if (!cli->win95)
>>>>>>>                 p += align_string(base_ptr, p, 0);
>>>>>> Have a nice day.
>>>>> Protocol sniffing for Windows 95/98 seems the wrong way to handle this.  Is there really no other way?
>>>>>
>>>>>
>>>> What is the meaning of 'protocol sniffing'?
>>> It is a term describing having differing behaviour based on the presumed
>>> implementation of the client, based on flags like 'is windows 95'.  Over
>>> time, we have generally come to regard such special cases as incorrect,
>>> that there is generally a more elegant, general and correct way to
>>> handle such things. 
>>>
>>> Andrew Bartlett
>>>
>> This flag is for the server we are connecting to.  Perhaps it is Unicode
>> vs. non-Unicode related.  Is there a (searchable and free) specification
>> that the devs go by here?  That such an old machine with the appropriate
>> patches may indeed align the string on the 2-byte boundaries.  I would
>> expect them to be 8-bit character strings when they are sent over the
>> wire.  They are, otherwise the symptom would be files appearing to not
>> have any filename rather than just missing the first letter.
> There is.  See http://msdn.microsoft.com/en-us/library/ee442092.aspx and
> http://msdn.microsoft.com/en-us/library/cc246231.aspx
>
> You can ask questions on the cifs-protocol at lists.samba.org list, you can
> ask questions of Microsoft at dochelp at microsoft.com, but CC the list if
> you do so others can also help and see the answer.
>
> Finally, please keep the samba-technical mailing list CC'ed, so others
> can help and you don't get lost in my personal inbox. 
>
> Andrew Bartlett
>

Alright.  I have found in the MS-CIFS spec section 2.2.1.1 titled
Character Sequences.  It goes on to say "when a Unicode string is passed
it MUST be aligned to a 16-bit boundary".  However it doesn't say all
smb_strings.  According to this, we should word align if and only if the
strings are Unicode.  It also says to use a null byte for padding to
achieve this.

This all depends on flags.  The good news is, that align_string does
this.  The function correctly returns 0 when STR_ASCII is set.  The
problem is, this function is not receiving any flags at all.  The last
argument passed is just zero no matter what.  Out of the ten arguments
passed to interpret_long_filename, can we get the flags from somewhere
that can potentially contain STR_ASCII?


Shawn Pringle