Re: [cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]
Hi Obaid, I'm still confused about the copychunk behavior. Let me reiterate what I understand, and then try to explain what I don't understand. 1. At the time of open, if the desired access included FILE_EXECUTE, then an SMB2 server would add FILE_READ_DATA to the granted access rights - this bit needs to be added to [MS-SMB2]. 2. COPYCHUNK: The only two restrictions mentioned about the dest handle are: a. that it must have FILE_READ_DATA access, b. that it must have either FILE_WRITE_DATA or FILE_APPEND_DATA, or both. 3. Combining the two together would imply that if we open the dest handle with FILE_EXECUTE | FILE_WRITE_DATA, then we'll be implicitly granted FILE_READ_DATA, and the copychunk would succeed. 4. Yet (and here's the part I don't understand), when trying the last thing, the copychunk fails with access-denied. You mentioned that there might be other reasons within the object store to reject the copychunk in this case. That's a case where the object store affects the observed behavior, and if at all possible I would like to understand the source of the object store's rejection of the copy, even if it falls outside MS-SMB2 (e.g. maybe it belongs in MS-FSA). I tried to be more prudent this time, and in the attached packet captures, the only difference between the successful copychunk in have_read.pcap and the failed one in no_read.pcap, is that the dest handle in the failed attempt was created without FILE_READ_DATA in the desired access. However, since it did have FILE_EXECUTE, I would expect that internally it would be granted FILE_READ_DATA, and the copy to succeed. Thanks, Uri. On 08/11/2016 12:43 AM, Obaid Farooqi wrote: > Hi Uri: > For object store on Windows, the execute permissions means read access is > automatic. The execute permission is called "Read&Execute" as noted here > https://msdn.microsoft.com/en-us/library/bb727008.aspx > The SMB server does extra permission checking as would be done by IO manager > if the operation were local. So I can clearly see that the read permission is > allowed at the time of create in the code and no additional permissions are > asked for at the time of read. > > As for the copychunk issue, the server is behaving as documented. So from > the standpoint of protocol document, there is nothing to do. > > I looked in the code for what you are describing and see that for copy chunk, > server checks for write and append permissions for target and return access > denied if that condition is not met. So the error, it appears, is bubbling > from object store. > If you want me to investigate further, I'll need some server side traces from > you. If yes, then let me know and I'll send you a tool to collect the traces > and also create a workspace where you can upload the resultant traces. > > Please let me know if it does not answer your question. > Also please let me know if you have any additional questions. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like to > provide feedback on your case you may contact my manager at ramagane at > Microsoft dot com > > -Original Message- > From: Uri Simchoni [mailto:u...@samba.org] > Sent: Thursday, August 4, 2016 3:28 AM > To: Obaid Farooqi > Cc: cifs-protocol@lists.samba.org; MSSolve Case Email > Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission > [116073114482785] > > Hi Obaid, > > That description implies that FILE_READ_DATA is granted at open time (NOT on > read time). To test that, I tested what happens with another operation - > COPYCHUNK, and got some confusing results. > > It seems that with COPYCHUNK, having FILE_EXECUTE on the *source* handle > would allow the copy, but having FILE_EXECUTE on the *destination* handle > (which also requires FILE_READ_DATA right) would not allow the copy. > > See attached (made against Server2012R2) - the first two attempts test the > source handle. Both are successful - one with FILE_READ_DATA and one without > FILE_READ_DATA but with FILE_EXECUTE. The next two attempts test the dest > handle, and the one without FILE_READ_DATA but with FILE_EXECUTE instead - > fails. > > Can you please clarify? > > My testing also confirms that SMB1 wouldn't let you do the same - it has > read_for_execute bit in the read request for that purpose. > > Thanks, > Uri > > On 08/04/2016 01:13 AM, Obaid Farooqi wrote: >> Hi Uri: >> My research shows that Windows SMB2 Servers (Vista/WS2008 and onwards) add >> FILE_READ_DATA to Open.GrantedAccess after file is opened and FILE_EXECUTE >> is granted by the object store. >> >> I did not find a similar pattern in the smb1 source. If you find otherwise, >> please let us know. >> >> I have filed a bug against MS-SMB2 document to include this behavior. >> >> Please let me know if this does not answer your question. >> Also please let me know if you have any further question(s). >> >> Regards, >>
Re: [cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]
Hi Obaid, I (hopefully) did as requested. I'd like to thank you for bearing with me on this one, this is much appreciated. Thanks, Uri. On 08/11/2016 09:33 PM, Obaid Farooqi wrote: > Hi Uri: > You must have received an email about creation of a workspace with > credentials to login. Please download the t.cmd file from there and copy it > to your Windows SMB server that you are using for this testing and follow the > steps below to collect and send me the traces. > > 1. Open an elevated command prompt and cd to the directory where you copied > t.cmd. For illustration I'll assume you copied it in c:\etw directory. > > 2. cd to c:\etw and execute the following command: > C:\etw> t.cmd srvon > 3. start a network capture > 4. reproduce the copychunk error > 5. Once done with error reproduction, execute the following command in the > same window you opened in step 1. > C:\etw>t.cmd srvoff > The above command will take couple of minutes to run and will create a file > whose name starts with t and has extension .cab > 6. stop network capture and save it. > 7. upload the cab file and network capture to the work space where you down > loaded the t.cmd file and let me know. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like to > provide feedback on your case you may contact my manager at ramagane at > Microsoft dot com > > -Original Message- > From: Uri Simchoni [mailto:u...@samba.org] > Sent: Thursday, August 11, 2016 1:35 AM > To: Obaid Farooqi > Cc: cifs-protocol@lists.samba.org; MSSolve Case Email > Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission > [116073114482785] > > Hi Obaid, > > I'm still confused about the copychunk behavior. > > Let me reiterate what I understand, and then try to explain what I don't > understand. > > 1. At the time of open, if the desired access included FILE_EXECUTE, then an > SMB2 server would add FILE_READ_DATA to the granted access rights - this bit > needs to be added to [MS-SMB2]. > > 2. COPYCHUNK: The only two restrictions mentioned about the dest handle are: > a. that it must have FILE_READ_DATA access, b. that it must have either > FILE_WRITE_DATA or FILE_APPEND_DATA, or both. > > 3. Combining the two together would imply that if we open the dest handle > with FILE_EXECUTE | FILE_WRITE_DATA, then we'll be implicitly granted > FILE_READ_DATA, and the copychunk would succeed. > > 4. Yet (and here's the part I don't understand), when trying the last thing, > the copychunk fails with access-denied. > > You mentioned that there might be other reasons within the object store to > reject the copychunk in this case. That's a case where the object store > affects the observed behavior, and if at all possible I would like to > understand the source of the object store's rejection of the copy, even if it > falls outside MS-SMB2 (e.g. maybe it belongs in MS-FSA). > > I tried to be more prudent this time, and in the attached packet captures, > the only difference between the successful copychunk in have_read.pcap and > the failed one in no_read.pcap, is that the dest handle in the failed attempt > was created without FILE_READ_DATA in the desired access. However, since it > did have FILE_EXECUTE, I would expect that internally it would be granted > FILE_READ_DATA, and the copy to succeed. > > Thanks, > Uri. > > On 08/11/2016 12:43 AM, Obaid Farooqi wrote: >> Hi Uri: >> For object store on Windows, the execute permissions means read access >> is automatic. The execute permission is called "Read&Execute" as noted >> here https://msdn.microsoft.com/en-us/library/bb727008.aspx >> The SMB server does extra permission checking as would be done by IO manager >> if the operation were local. So I can clearly see that the read permission >> is allowed at the time of create in the code and no additional permissions >> are asked for at the time of read. >> >> As for the copychunk issue, the server is behaving as documented. So from >> the standpoint of protocol document, there is nothing to do. >> >> I looked in the code for what you are describing and see that for copy >> chunk, server checks for write and append permissions for target and return >> access denied if that condition is not met. So the error, it appears, is >> bubbling from object store. >> If you want me to investigate further, I'll need some server side traces >> from you. If yes, then let me know and I'll send you a tool to collect the >> traces and also create a workspace where you can upload the resultant traces. >> >> Please let me know if it does not answer your question. >> Also please let me know if you have any additional questions. >> >> Regards, >> Obaid Farooqi >> Escalation Engineer | Microsoft >> >> Exceeding your expectations is my highest priority. If you would like >> to provide feedback on your case you may contact my manager at >> ra
Re: [cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]
Hi Obaid, I think I understand it now: - This extra FILE_READ_DATA that's granted due to the FILE_EXECUTE permission is not visible to the object store - In normal read/write operations, the object store is not performing access checks, it's entirely the responsibility of the SMB2 server (put another way, the SMB2 server has access to lower-level APIs which are past the security check point), and since in the SMB server's view, the handle has FILE_READ_DATA access, the read is allowed. - In ioctl calls, the object store does perform an access check based on the ioctl code and its view of the file handle, and that check fails. I'm just trying to grasp the correct model, both for this case and for future cases. If any of this is grossly wrong, I'd be happy to be corrected, otherwise I think my questions are answered. Thanks again, Uri. On 08/12/2016 02:25 AM, Obaid Farooqi wrote: > Hi Uri: > Here is why copy chunk is failing if file is opened without read permissions. > At the kernel level, if the command is an FSCTL, the access is check based on > the CtlCode. > This blog explains how you can calculate the access mode required for an > IOCTL: > http://social.technet.microsoft.com/wiki/contents/articles/24653.decoding-io-control-codes-ioctl-fsctl-and-deviceiocodes-with-table-of-known-values.aspx > > > At kernel level, the check for read command is done against IRP_MJ_READ > whereas the copychunk test for access is done against > IRP_MJ_FILE_SYSTEM_CONTROL which is a different test and involves CtrlCode. > > This is the reason you see a discrepancy in behavior although SMB server has > allowed the read access when file is opened with execute. > > Please let me know if this does not answer your question. > Also let me know if you have more questions. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like to > provide feedback on your case you may contact my manager at ramagane at > Microsoft dot com > > -Original Message- > From: Uri Simchoni [mailto:u...@samba.org] > Sent: Thursday, August 11, 2016 2:02 PM > To: Obaid Farooqi > Cc: cifs-protocol@lists.samba.org; MSSolve Case Email > Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission > [116073114482785] > > Hi Obaid, > > I (hopefully) did as requested. > I'd like to thank you for bearing with me on this one, this is much > appreciated. > > Thanks, > Uri. > > On 08/11/2016 09:33 PM, Obaid Farooqi wrote: >> Hi Uri: >> You must have received an email about creation of a workspace with >> credentials to login. Please download the t.cmd file from there and copy it >> to your Windows SMB server that you are using for this testing and follow >> the steps below to collect and send me the traces. >> >> 1. Open an elevated command prompt and cd to the directory where you copied >> t.cmd. For illustration I'll assume you copied it in c:\etw directory. >> >> 2. cd to c:\etw and execute the following command: >> C:\etw> t.cmd srvon >> 3. start a network capture >> 4. reproduce the copychunk error >> 5. Once done with error reproduction, execute the following command in the >> same window you opened in step 1. >> C:\etw>t.cmd srvoff >> The above command will take couple of minutes to run and will create a >> file whose name starts with t and has extension .cab 6. stop network capture >> and save it. >> 7. upload the cab file and network capture to the work space where you down >> loaded the t.cmd file and let me know. >> >> Regards, >> Obaid Farooqi >> Escalation Engineer | Microsoft >> >> Exceeding your expectations is my highest priority. If you would like >> to provide feedback on your case you may contact my manager at >> ramagane at Microsoft dot com >> >> -Original Message- >> From: Uri Simchoni [mailto:u...@samba.org] >> Sent: Thursday, August 11, 2016 1:35 AM >> To: Obaid Farooqi >> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email >> >> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission >> [116073114482785] >> >> Hi Obaid, >> >> I'm still confused about the copychunk behavior. >> >> Let me reiterate what I understand, and then try to explain what I don't >> understand. >> >> 1. At the time of open, if the desired access included FILE_EXECUTE, then an >> SMB2 server would add FILE_READ_DATA to the granted access rights - this bit >> needs to be added to [MS-SMB2]. >> >> 2. COPYCHUNK: The only two restrictions mentioned about the dest handle are: >> a. that it must have FILE_READ_DATA access, b. that it must have either >> FILE_WRITE_DATA or FILE_APPEND_DATA, or both. >> >> 3. Combining the two together would imply that if we open the dest handle >> with FILE_EXECUTE | FILE_WRITE_DATA, then we'll be implicitly granted >> FILE_READ_DATA, and the copychunk would succeed. >> >> 4. Yet (and here's the part I don't understand), when trying the last thing, >> the copychunk fails
[cifs-protocol] [MS-SMB] - status code of NT_TRANS_QUERY_QUOTA
Hi, In [MS-SMB], section 3.3.5.11.2 "Receiving an NT_TRANS_QUERY_QUOTA Request", it is indicated that: If the entire quota information cannot fit in the response buffer, then the server MUST return a status of STATUS_BUFFER_TOO_SMALL. Otherwise, the server MUST return STATUS_SUCCESS. In practice (trying against Server 2012R2) I see that the server returns STATUS_SUCCESS as long as it has more entries, and STATUS_NO_MORE_ENTRIES when there are no more entries. Can you please clarify? Thanks, Uri. ___ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:116091614680032] [MS-SMB] - status code of NT_TRANS_QUERY_QUOTA
On 09/16/2016 07:23 PM, Bryan Burgin wrote: > [Josh to bcc] > > Hi Uri, > > I can review this for you. Is your observation that we never return > STATUS_BUFFER_TOO_SMALL? It's either STATUS_SUCCESS or > STATUS_NO_MORE_ENTRIES? Do you have traces? > > Bryan > > I've seen STATUS_BUFFER_TOO_SMALL only if MaxDataCount is not enough for a single quota record. Otherwise it's a series of OK's that end with a STATUS_NO_MORE_ENTRIES. BTW, this is the documented [MS-SMB2] behavior. Attached pls find a packet trace. MaxDataCount has been purposefully made small here to show a series of requests. Thanks, Uri. quota-list.pcap Description: application/vnd.tcpdump.pcap ___ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:116091614680032] [MS-SMB] - status code of NT_TRANS_QUERY_QUOTA
Thanks! Uri On 09/21/2016 08:54 PM, Bryan Burgin wrote: > Hi Uri, > > I verified your findings and files an issue against [MS-SMB]. Requested > change: > > Update [MS-SMB] 3.3.5.11.2 "Receiving an NT_TRANS_QUERY_QUOTA Request" to > reflect: > > Send STATUS_BUFFER_TOO_SMALL if no buffer was indicated or a buffer too small > to hold a single entry > Send STATUS_SUCCESS to indicate the return of valid entries and as a signal > that there are more (to re-post a new buffer) > Send STATUS_NO_MORE_ENTRIES when the last entry was sent. > > Bryan > > -Original Message- > From: Bryan Burgin > Sent: Friday, September 16, 2016 12:54 PM > To: Uri Simchoni > Cc: cifs-protocol@lists.samba.org; MSSolve Case Email > Subject: RE: [REG:116091614680032] [MS-SMB] - status code of > NT_TRANS_QUERY_QUOTA > > Thx. I was reviewing ZwQueryQuotaInformationFile(), which this call relies > on, and surmised that STATUS_BUFFER_TOO_SMALL is returned only if a buffer > was supplied that was too small for a single entry. Thanks for confirming. > I'll review the rest and file a report against [MS-SMB]. > > Bryan > > -Original Message- > From: Uri Simchoni [mailto:u...@samba.org] > Sent: Friday, September 16, 2016 12:50 PM > To: Bryan Burgin > Cc: cifs-protocol@lists.samba.org; MSSolve Case Email > Subject: Re: [REG:116091614680032] [MS-SMB] - status code of > NT_TRANS_QUERY_QUOTA > > On 09/16/2016 07:23 PM, Bryan Burgin wrote: >> [Josh to bcc] >> >> Hi Uri, >> >> I can review this for you. Is your observation that we never return >> STATUS_BUFFER_TOO_SMALL? It's either STATUS_SUCCESS or >> STATUS_NO_MORE_ENTRIES? Do you have traces? >> >> Bryan >> >> > > I've seen STATUS_BUFFER_TOO_SMALL only if MaxDataCount is not enough for a > single quota record. Otherwise it's a series of OK's that end with a > STATUS_NO_MORE_ENTRIES. BTW, this is the documented [MS-SMB2] behavior. > > Attached pls find a packet trace. MaxDataCount has been purposefully made > small here to show a series of requests. > > Thanks, > Uri. > ___ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB1 processing of FileRnameInfo
Hi, I tried renaming files over SMB1 protocol using pass-through info-level of FileRenameInfo (cf [MS-SMB] 2.2.2.3.5). When doing this against a Windows 2012R2 machine, it fails with STATUS_NOT_SUPPORTED. The advantage of using FileRenameInfo instead of using SMB Rename would be that if the destination file exists, the rename can be atomic without having to delete the destination file first. Looking for encoding / other errors in my client code, I tried to see what Windows does as a client. I wrote a short program that uses SetFileInformationByHandle(). The program worked, but to my surprise, the Windows client didn't pass through the FileRenameInfo over SMB. Rather it deleted the dest file and made an SMB Rename call (that is, two operations). All this seems to suggest that pass-through of FileRenameInfo is not supported over SMB1 by Windows servers. Attached pls find a packet capture of the rename attempt (using Samba client code). The client creates test1.txt, then creates test.txt and tries renaming that to test1.txt, overwriting the older file. Thanks, Uri. smb1-remame-info.pcap Description: application/vnd.tcpdump.pcap ___ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:117050715700170] SMB1 processing of FileRnameInfo
On 05/09/2017 09:38 PM, Bryan Burgin wrote:
> After carefully reading your text, I won't need your program.
> I'll see if there is a different way to make a client send the
> FileRenameInfo/Passthru command.
> B.
>
FWIW, program attached.
(notice that paths are hard-coded and files are assumed to be pre-existing).
Thanks,
Uri.
> -Original Message-
> From: Bryan Burgin
> Sent: Tuesday, May 9, 2017 8:54 AM
> To: Uri Simchoni
> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
> Subject: RE: [REG:117050715700170] SMB1 processing of FileRnameInfo
>
> Hi Uri,
>
> I can research this for you. Let me look at the code. Can you send me the
> source of your test program; that will save me the time of doing the same.
>
> Bryan
#include
#include
#include
#include
#include
int main()
{
auto const& filepath = L"Z:\\1.txt";
auto const& destpath = L"Z:\\2.txt";
// handles will be leaked but that should be irrelevant here
auto const f_handle = CreateFile(filepath,
GENERIC_READ | GENERIC_WRITE | DELETE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
if (f_handle == INVALID_HANDLE_VALUE)
{
auto const err = GetLastError();
std::cerr << "failed to create test file: " << err;
return err;
}
auto const destpath_bytes_withOUT_null = wcslen(destpath);
// unclear if we need to subtract the one wchar_t of FileNameLength:
auto const struct_size = sizeof(FILE_RENAME_INFO) + (destpath_bytes_withOUT_null + 1) * sizeof(WCHAR);
FILE_RENAME_INFO* fri = (FILE_RENAME_INFO*)new BYTE[struct_size];
fri->ReplaceIfExists = TRUE; // as described by Niall Douglas
fri->RootDirectory = NULL;//parent_dir_handle;
// with or without null terminator?
fri->FileNameLength = (DWORD)destpath_bytes_withOUT_null;// No include null
wcscpy(fri->FileName, destpath);
BOOL res = SetFileInformationByHandle(f_handle, FileRenameInfo,
fri, (DWORD)struct_size);
delete fri;
if (!res)
{
auto const err = GetLastError();
std::cerr << "failed to rename file: " << err;
return err;
}
else
std::cout << "success";
res = CloseHandle(f_handle);
if (!res)
{
auto const err = GetLastError();
std::cerr << "failed to close file: " << err;
return err;
}
return 0;
}___
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:117050715700170] SMB1 processing of FileRnameInfo
Back to my client code -
- Both smbclient and my modified smbtorture3 RENAME test use a leading
'\' in file name. BTW, SMB2 and later, that leading '\' is cleared by
the client library, that is - the application requests '\file'.
- When I remove the leading '\', it worked as you predicted.
- When there's a '\' anywhere in the dest file name, it doesn't work
(NT_STATUS_NOT_SUPPORTED) - not just leading. That means rename+replace
in SMB1 is limited to dest being at the root of the share.
So to sum things up - it appears that SMB1 Windows server supports
rename via pass-through FileRenameInfo only if the destination is at the
root of the share, and destination specified without a leading '\'. It
also appears that this is due to incomplete implementation.
Thanks for digging this up for me :)
Uri
On 05/17/2017 09:24 PM, Bryan Burgin wrote:
> From usermode using Win32 APIs on a Windows client, I believe it is
> impossible to create the transaction you're trying to emit on-the-wire.
>
> I used your program and made one of my own, too. When either of our programs
> calls SetFileInformationByHandle() it calls Win32Rename(), based on the info
> class FileRenameInfo. Within Win32Rename(), it calls
> RtlDosPathNameToNtPathName_U_WithStatus() on the newname to do "NT path
> translation" that converts it to "\??\X:\NewFile.txt" -- regardless of how
> you specified it in your call (with a leading '\', with a leading 'X:\', with
> a leading 'X:' or just without any drive indication ("NewFile.txt").
>
> All the above is done in usermode in kernelbase.dll bound to your process
> long before the request drops into the Kernel and eventually in our
> redirector that, which, as I indicated yesterday, sees the leading '\' and
> decides to do this old-school: delete NewFile (in case it's there), then call
> Rename. There appears to be nothing you can do in your Win32 call that will
> protect your buffer from being translated before being passed to the
> redirector. I investigated if there were raw NtXxxx or ZwX calls that
> could be made instead. There are none for SetFileInformationByHandle.
>
> Thus, we should abandon creating this traffic via Win32 APIs and concentrate
> on the call your client is making. What happens if the NewFile does not
> already exist? What happens if you don't have a leading '\', as I saw on
> your trace? It does appear, from the message I sent yesterday that support
> for pass-through Rename on the server is limited.
>
> Bryan
>
> -Original Message-
> From: Bryan Burgin
> Sent: Tuesday, May 16, 2017 10:56 AM
> To: 'Uri Simchoni'
> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
> Subject: RE: [REG:117050715700170] SMB1 processing of FileRnameInfo
>
> Hi, Uri,
>
> I found where we service this call on our client-side redirector. We have a
> note that the server-side is not completely implemented and that we will
> revert to the style you cite if RootDirectory is non-NULL or if a '\\' exists
> in the TargetName (FileName) -- essentially making the 'Rename' into a
> 'Move'. In your trace, I see that you have a leading backslash. While a
> leading backslash (and none others) would mean the rename is relative to
> where the file is presently (not a move) the code just looks for the presence
> of any backslashes.
>
> Can you test this on your end and see if it changes your observation? I will
> look at the code you provided, too.
>
> Bryan
>
> -Original Message-
> From: Uri Simchoni [mailto:u...@samba.org]
> Sent: Tuesday, May 9, 2017 9:01 PM
> To: Bryan Burgin
> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
> Subject: Re: [REG:117050715700170] SMB1 processing of FileRnameInfo
>
> On 05/09/2017 09:38 PM, Bryan Burgin wrote:
>> After carefully reading your text, I won't need your program.
>> I'll see if there is a different way to make a client send the
>> FileRenameInfo/Passthru command.
>> B.
>>
> FWIW, program attached.
> (notice that paths are hard-coded and files are assumed to be pre-existing).
> Thanks,
> Uri.
>
>> -Original Message-
>> From: Bryan Burgin
>> Sent: Tuesday, May 9, 2017 8:54 AM
>> To: Uri Simchoni
>> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
>>
>> Subject: RE: [REG:117050715700170] SMB1 processing of FileRnameInfo
>>
>> Hi Uri,
>>
>> I can research this for you. Let me look at the code. Can you send me the
>> source of your test program; that will save me the time of doing the same.
>>
>> Bryan
___
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:117050715700170] SMB1 processing of FileRnameInfo
On 05/17/2017 11:09 PM, Bryan Burgin wrote: > Concurrently, after shifting focus from the Win32 API question, I found our > validation code on the server side. We have code that " If there are any > path separators in the name, then we do not support this operation." > Are you sure about " That means rename+replace in SMB1 is limited to dest > being at the root of the share."? It seems that if the CreateFile was > against "dir\anotherdir\filename.txt" and you just included "newname.txt" in > the tunneled rename, it would work. In other words, all the path info is in > the original CreateFile call. Can you test that as I don't have the > environment (an environment that can emit the request from a client)? > > Bryan Confirmed. It appears as though in SMB1, the destination is relative to the source file (thereby allowing rename in the same directory, any directory), whereas with SMB2, the destination is relative to the root of the share (and supporting move between directories). If that's correct, then [MS-FSCC] is in error, as 2.4.34.1 says: "...For network operations, this pathname is relative to the root of the share" BTW, Samba also works that way (SMB1 server interprets the destination as relative to source's parent directory, SMB2 server interprets the destination as relative to the share's root. Somehow we got that right although we don't seem to have torture tests to prove it. Seems like I need to fix my recent addition of "-f" flag to smbclient rename command. Thanks for helping me clear this up, Uri. ___ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:117102016529426] SMB2 File Rename
Chiming in because I also had rename-related investigations (I don't
think this answers the original question but it is relevant to the
response):
- smbclient does SMB1 rename using cifs rename, not using FILE_RENAME_INFO
- so does Windows (or so it seems)
- smbclient can be made to use FILE_RENAME_INFO using the -f option
- however, the -f implementation for NT1 is broken because NT1 expects
the dest file to be relative to directory of source file, and cannot
move it to another dir (SMB2 onwards expects the dest to be relative to
share's root and *can* move file between dirs
The attached patch set to Samba includes a torture test that
demonstrates all that (passes against both Samba and Windows 10)
Thanks,
Uri.
On 10/25/2017 10:18 PM, Sreekanth Nadendla via cifs-protocol wrote:
> Hello Andreas, in the sample traces you've sent us, I can see the setInfo
> request with SMB2_FILE_RENAME_INFO for SMB2 case. However I don't see similar
> rename structure from your first trace rename_nt1. Let me know if I'm
> missing something.
>
> On windows OS, rename command does not allow you to specify a new drive
> (device) or *path* for the destination file. Before I dig in further with
> "move" command in my investigation, I would like to see from your traces
> exactly how the request was sent to server in the case of SMB v1. Also if
> you can, please confirm if the same Windows 2012 server is used when your
> client was using SMB v3.
>
>
> Regards,
> Sreekanth Nadendla
> Microsoft Windows Open Specifications
>
> -Original Message-
> From: Sreekanth Nadendla
> Sent: Friday, October 20, 2017 11:16 AM
> To: Andreas Schneider
> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
> Subject: [REG:117102016529426] SMB2 File Rename
>
> Hello Andreas, I will be assisting you with your issue. I am currently
> researching the problem and will provide you with an update soon. Thank you
> for your patience.
>
> Regards,
> Sreekanth Nadendla
> Microsoft Windows Open Specifications
>
> -Original Message-
> From: Andreas Schneider [mailto:a...@samba.org]
> Sent: Friday, October 20, 2017 6:21 AM
> To: Interoperability Documentation Help
> Cc: cifs-protocol@lists.samba.org
> Subject: SMB2 File Rename
>
> Hello,
>
> I disovered that a file rename operation (SetInfo with
> FILE_RENAME_INFORMATION_TYPE_2) fails for a SMB3 connection but works for
> SMB1.
>
> I've run smbclient from Samba again Windows 2012:
>
> File rename (move) over SMB1 with smbclient:
>
> bin/smbclient //win-dc02.earth.milkyway.site/Test -Ubob1%Secret007! -mNT1 Try
> "help" to get a list of possible commands.
> smb: \> cd dir1
> smb: \dir1\> rename README ..\dir2\README
> smb: \dir1\>
>
> This works!
>
> File rename (move) over SMB3 with smbclient:
>
> bin/smbclient //win-dc02.earth.milkyway.site/Test -Ubob1%Secret007! -mSMB3
> Try "help" to get a list of possible commands.
> smb: \> cd dir1
> smb: \dir1\> rename README ..\dir2\README NT_STATUS_OBJECT_NAME_NOT_FOUND
> renaming files \dir1\README -> \dir1\..
> \dir2\README
> smb: \dir1\>
>
> As you can see, it fails with NT_STATUS_OBJECT_NAME_NOT_FOUND.
>
> I do not see that we're doing anything wrong in the SetInfo request. The doc
> does not mention that '..' is not allowed.
>
> Is a path of dir1\..\dir2\file not allowed?
>
>
> Attached are the network traces.
>
>
> Thanks for your help!
>
>
> Best regards,
>
>
> Andreas
>
>
From c5c185f510eee0729b5b6abeb5209c89ac3537fd Mon Sep 17 00:00:00 2001
From: Uri Simchoni
Date: Thu, 7 Sep 2017 18:12:25 +0300
Subject: [PATCH 1/3] cli: add low-level synchronous NT1 rename
Add a synchronous function that invokes rename via
FILE_RENAME_INFORMATION passthrough, in the NT1
dialect. This adds on the async version that already
exists, and is meant for use by torture tests.
Signed-off-by: Uri Simchoni
---
source3/libsmb/clifile.c | 47 +++
source3/libsmb/proto.h | 4
2 files changed, 51 insertions(+)
diff --git a/source3/libsmb/clifile.c b/source3/libsmb/clifile.c
index a6a0baf..548c99e 100644
--- a/source3/libsmb/clifile.c
+++ b/source3/libsmb/clifile.c
@@ -1094,6 +1094,53 @@ fail:
return tevent_req_post(req, ev);
}
+NTSTATUS cli_smb1_rename(struct cli_state *cli,
+ const char *fname_src,
+ const char *fname_dst,
+ bool replace)
+{
+ TALLOC_CTX *frame = NULL;
+ struct tevent_context *ev;
+ struct tevent_req *req;
+ NTSTATUS status = NT_STATUS_OK;
+
+ if (smbXcli_conn_protocol(cli->conn) >= PROTOCOL_SMB2_02) {
+ return NT_STATUS_INVALID_PARAMETER;
+ }
+
+ frame = talloc_stackframe();
+
+ if (smbXcli_conn_has_async_calls(cli->conn)) {
+ /*
+* Can't use sync call while an async call is in flight
+*/
+ status = NT_STATUS_INVALID_PARAMETER;
+ goto fail;
+ }
+
