SMB3 issues with smbclient

[Stefan Metzmacher]

Hi Paul,

>>> On 20/12/16 11:18, Jeremy Allison wrote:
>>>> On Tue, Dec 20, 2016 at 10:48:35AM +1030, Paul Smedley wrote:
>>>>> Hi All,
>>>>>
>>>>> As I've posted previously, I'm working on a Samba client for the OS/2
>>>>> operating system, which is a fuse style plugin for 'netdrive'.
>>>>>
>>>>> I've just discovered what I think is a bug in SMB2+ support, which
>>>>> I believe
>>>>> also exists in smbclient.
>>>>>
>>>>> A user reported a problem to me, with file corruption when saving a
>>>>> file to
>>>>> a Samba share (the file ends up as 0 bytes),
>>>>>
>>>>> I believe this is due to an an incorrect fnum being returned from
>>>>> cli_open()
>>>>> when SMB2 is used.
>>>>>
>>>>> In my own code, with a file being opened over SMB1, I get fnum in
>>>>> the 10000+
>>>>> range which I'd expect. Additionally, each file opened gets a
>>>>> differeent
>>>>> fnum.
>>>>>
>>>>> When a file is opened via SMB2, in my code fnum is always 1.
>>>>>
>>>>> I tried similar operations using smbclient - similar things occur:
>>>>> - SMB1 I get valid fnum returned
>>>>> - SMB3 I get a fnum of 2 (why this is different to my own testcase
>>>>> I'm not
>>>>> sure)
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Should cli_open() be returning a valid valid for fnum when SMB3 is
>>>>> used?
>>>>
>>>> What version of Samba ? In current 4.5.x cli_open() under the covers
>>>> will create an SMB1/2/3 handle depending on what has been negotiated
>>>> on the wire.
>>>>
>>> 4.4.7 - I added a d_printf("fnum = %d\n",fnum); after the first
>>> cli_open()
>>> call in smbclient and with default settings (ie SMB1) get an fnum like
>>> 26614; with -mSMB3 - it's always 2.
>>>
>>> I can test with 4.5.x if you think it's worthwhile.
>>
>> As it's client code it should be relatively easy
>> to walk through with gdb and watch where it goes
>> into the SMB2 requests and see what's going wrong.
>>
> FWIW - same behaviour under linux smbclient with 4.4.8 and 4.5.3

Why do you think the value '2' is invalid?

The thing is that we allocate the numbers locally and have
an in memory mapping from the number to the SMB volatile and persistent
file id values.

See source3/libsmb/cli_smb2_fnum.c map_smb2_handle_to_fnum(),
map_fnum_to_smb2_handle() and delete_smb2_handle_mapping().

idr_get_new_above() always returns the lowest possible (unused) number,
so with an open/close, open/close, open/close pattern we'll
always return the same number, while they point to different
smb2_hnd structures.

It would be interesting know if there's actually a real problem.

What was the problem in your case? Did you send the value "1" over
the net?

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20161220/fc49186e/signature-0001.sig>