Samba 3.6.6 and above return NT_STATUS_FILE_CLOSED rather than STATUS_INVALID_DEVICE_REQUEST

[Richard Sharpe]

On Tue, Dec 4, 2012 at 3:37 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Tue, Dec 4, 2012 at 3:24 PM, Jeremy Allison <jra at samba.org> wrote:
>> On Tue, Dec 04, 2012 at 03:04:31PM -0800, Richard Sharpe wrote:
>>
>>> Hmmm, regardless of whether we are doing the correct thing or the
>>> wrong thing in general, it looks like the problem is that this
>>> occurred in a compound operation consisting of a CREATE followed by an
>>> IOCTL for an FSCTL and that the FSP from the create was not forwarded
>>> to the IOCTL handling code.
>>>
>>> [2012/12/04 14:59:00.227924, 10] smbd/smb2_server.c:2572(smbd_smb2_request_incom
>>> ing)
>>>   smbd_smb2_request_incoming: idx[1] of 4 vectors
>>> [2012/12/04 14:59:00.228000, 10] smbd/smb2_server.c:354(smb2_validate_message_id
>>> )
>>>   smb2_validate_message_id: clearing id 32 (position 32) from bitmap
>>> [2012/12/04 14:59:00.228045, 10] smbd/smb2_server.c:1222(smbd_smb2_request_dispa
>>> tch)
>>>   smbd_smb2_request_dispatch: opcode[SMB2_IOCTL] mid = 32
>>> [2012/12/04 14:59:00.228089,  4] smbd/uid.c:351(change_to_user)
>>>   Skipping user change - already user
>>> [2012/12/04 14:59:00.228269, 10] smbd/smb2_ioctl.c:253(smbd_smb2_ioctl_send)
>>>   smbd_smb2_ioctl: ctl_code[0x00110018] <no handle> fnum[-1]
>>> [2012/12/04 14:59:00.228413, 10] smbd/smb2_ioctl.c:376(smbd_smb2_ioctl_send)
>>>   Returning FILE_CLOSED (THIS IS MY DEBUGGING LINE TO SEE WHERE the
>>> ERROR is coming from.)
>>> [2012/12/04 14:59:00.228491, 10] smbd/smb2_ioctl.c:141(smbd_smb2_request_ioctl_d
>>> one)
>>>   smbd_smb2_request_ioctl_done: smbd_smb2_ioctl_recv returned 0 status NT_STATUS
>>> _FILE_CLOSED
>>
>> This should be being done by :
>>
>> smb2req->compat_chain_fsp
>>
>> which is set from the result of the SMB2_CREATE op.
>>
>> Then inside smbd/smb2_ioctl.c it calls file_fsp_smb2()
>> which contains:
>>
>>         if (smb2req->compat_chain_fsp != NULL) {
>>                 return smb2req->compat_chain_fsp;
>>         }
>>
>> so it should be using the fsp pointer from the
>> previous create.
>
> This seems to be the relevant code:
>
>         if (in_file_id_persistent == UINT64_MAX &&
>                    in_file_id_volatile == UINT64_MAX) {
>                 /* without a handle */
>         } else {
>                 in_fsp = file_fsp_smb2(req, in_file_id_persistent,
>                                         in_file_id_volatile);
>                 if (in_fsp == NULL) {
>                         return smbd_smb2_request_error(req,
> NT_STATUS_FILE_CLOSED);
>                 }
>         }
>
> The values from the packet are two 64-bit numbers both with
> FFFFFFFFFFFFFFFF in them, so the first path seems to be exercised, but
> it seems wrong ...

OK, the problem has been dealt with in 3.6-next.

Sigh. Being stuck with 3.6.6 at the moment sucks.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)