Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Bill Wesse]

Good morning Tim. Bill Wesse from the Documentation Support team here. I will 
be your contact for this issue. We have created the following case to track our 
investigation:

SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode

I will begin work this morning, and will update you with status before the end 
of the day.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606

-Original Message-
From: Tim Prouty [mailto:tim.pro...@isilon.com] 
Sent: Tuesday, November 24, 2009 6:07 PM
To: Interoperability Documentation Help; cifs-proto...@samba.org; 
p...@tridgell.net
Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing 
share modes

Hi,

Based on the ZwSetInformationFile() docs
(http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of 
smb1 against a win7 share, in order to set FileEndOfFileInformation it is 
necessary that the file is first opened with FILE_WRITE_DATA in the 
access_mask.  It then follows that a Trans2SetPathInfo for 
FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA 
before either truncating or extending the file.

The specific case I'm interested in is the following:

1. Client1 does a CreateFileAndX() on a non-existant file with a share
mode of 0 and holds the file open.

2. Client 2 does a Trans2SetPathInfo() with the level set to
FileEndOfFileInformation (0x104) as documented in the SNIA CIFS
spec.  As expected NT_STATUS_SHARING_VIOLATION is returned here.

3. Client 2 does a Trans2SetPathInfo() with the undocumented
pass-through level that also allows setting the
FileEndOfFileInformation (1020 / 0x3FC).  The client specifies that
it wants to extend the file size to 100.  Interestingly, win7 and
winXP will return NT_STATUS_SUCCESS and successfully extend the
length of the file.  This operation seems to be circumventing the
share mode enforcement.

Is #3 actually correct behavior that other servers should implement?
If so, can the cases where share modes are not enforced be enumerated in the 
documentation?

I have attached a pcap of a client executing these exact steps against a win7 
server.

Packet 27/28: Step 1
Packet 29/30: Step 2
Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 
37/38: Show that share modes should still be enforced.

Thanks!

-Tim

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Bill Wesse]

Hello Tim. I think the difference in the response between the standard versus 
pass-through level lies in how the file handle is obtained during the call 
(given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). 
The logical conclusion from the trace is that pass-through gets the existing 
handle, and the non pass-through value simply fails, because a new handle 
cannot be opened due to the lack of sharing.

I will continue my investigation into the details on the differences between 
the base & pass-through handling, with respect to the file path / handle 
source. Pass-through is basically implementation dependent, as noted in 
[MS-FSCC] (reference below), so there is a possibility this may not be further 
elaborated on in the documents.

Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through 
value), since that requires the file handle (per [MS-CIFS] 2.2.6.9 
TRANS2_SET_FILE_INFORMATION (0x0008) at 
http://msdn.microsoft.com/en-us/library/ee442064.aspx).

SMB_INFO_PASSTHROUGH levels request a native Windows NT operating system 
information level (as you already have noted) of the TRANS2_SET_* & 
TRANS2_QUERY_* calls, and can be thought of as rough equivalents to 
ZwSetInformationFile and ZwQueryInformationFile:

1. Where the 'FILE_INFORMATION_CLASS FileInformationClass' parameter is equal 
to:   

   (InformationLevel - SMB_INFO_PASSTHROUGH) : See MSDN 
WDF_FILE_INFORMATION_CLASS at
   http://msdn.microsoft.com/en-us/library/dd568296.aspx

2. The InformationLevels are restricted as noted in:

   [MS-SMB] 6 Appendix A: Product Behavior <158>, <239>, <240> and <242> at
   http://msdn.microsoft.com/en-us/library/cc246806.aspx

[MS-FSCC] 5 Appendix A: Product Behavior note <47> specifies "Windows uses the 
NtQueryInformationFile ... NtSetInformationFile ... The definition of the 
function used to process any file information request, including its content 
and the function signature, is implementation-dependent and is not part of the 
protocol specification".

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606


-Original Message-
From: Bill Wesse 
Sent: Wednesday, November 25, 2009 8:30 AM
To: 'Tim Prouty'
Cc: cifs-proto...@samba.org; p...@tridgell.net
Subject: RE: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing 
share modes

Good morning Tim. Bill Wesse from the Documentation Support team here. I will 
be your contact for this issue. We have created the following case to track our 
investigation:

SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode

I will begin work this morning, and will update you with status before the end 
of the day.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606

-Original Message-
From: Tim Prouty [mailto:tim.pro...@isilon.com] 
Sent: Tuesday, November 24, 2009 6:07 PM
To: Interoperability Documentation Help; cifs-proto...@samba.org; 
p...@tridgell.net
Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing 
share modes

Hi,

Based on the ZwSetInformationFile() docs
(http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of 
smb1 against a win7 share, in order to set FileEndOfFileInformation it is 
necessary that the file is first opened with FILE_WRITE_DATA in the 
access_mask.  It then follows that a Trans2SetPathInfo for 
FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA 
before either truncating or extending the file.

The specific case I'm interested in is the following:

1. Client1 does a CreateFileAndX() on a non-existant file with a share
mode of 0 and holds the file open.

2. Client 2 does a Trans2SetPathInfo() with the level set to
FileEndOfFileInformation (0x104) as documented in the SNIA CIFS
spec.  As expected NT_STATUS_SHARING_VIOLATION is returned here.

3. Client 2 does a Trans2SetPathInfo() with the undocumented
pass-through level that also allows setting the
FileEndOfFileInformation (1020 / 0x3FC).  The client specifies that
it wants to extend the file size to 100.  Interestingly, win7 and
winXP will return NT_STATUS_SUCCESS and successfully extend the
length of the file.  This operation seems to be circumventing the
share mode enforcement.

Is #3 actually correct behavior that other servers should implement?
If so, can the cases where share modes are not enforced be enumerated in the 
documentation?

I have attached a pcap of a client executing these exact steps against a win7 
server.

Packet 27/28: Step 1
Packet 29/30: Step 2
Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 
37/38: Show that share modes should still be enforced.

Thanks!

-Tim

__

Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Tim Prouty]

Hi Bill,

Thank you for the quick answer!  I have a few comments/questions below.

On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote:

Hello Tim. I think the difference in the response between the  
standard versus pass-through level lies in how the file handle is  
obtained during the call (given that TRANS2_SET_PATH_INFORMATION  
passes the path, and not the handle). The logical conclusion from  
the trace is that pass-through gets the existing handle, and the non  
pass-through value simply fails, because a new handle cannot be  
opened due to the lack of sharing.



Which existing handle would the pass-through be using?  The handle
opened in packet #28 is a separate tcp connection and a separte
session from the Trans2SetPathInfo in packet #33.  I'm not aware of
any situation where the server is expected to share file handles
across multiple sessions.  Is this an exception?


I will continue my investigation into the details on the differences  
between the base & pass-through handling, with respect to the file  
path / handle source. Pass-through is basically implementation  
dependent, as noted in [MS-FSCC] (reference below), so there is a  
possibility this may not be further elaborated on in the documents.



If a client can send a particular info level and windows implements
it, then we have a compatibility problem if we choose not to support
it.  What I would really like to know is if other SMB implementations
need to circumvent share-mode checks for this pass through level (and
maybe others?).


Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a  
pass-through value), since that requires the file handle (per [MS- 
CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx) 
.



I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the
same session would have succeeded.

-Tim
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Jeremy Allison]

On Wed, Nov 25, 2009 at 05:14:26PM +, Bill Wesse wrote:
> Hello Tim. I think the difference in the response between the standard versus 
> pass-through level lies in how the file handle is obtained during the call 
> (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). 
> The logical conclusion from the trace is that pass-through gets the existing 
> handle, and the non pass-through value simply fails, because a new handle 
> cannot be opened due to the lack of sharing.
> 
> I will continue my investigation into the details on the differences between 
> the base & pass-through handling, with respect to the file path / handle 
> source. Pass-through is basically implementation dependent, as noted in 
> [MS-FSCC] (reference below), so there is a possibility this may not be 
> further elaborated on in the documents.

That won't wash I'm afraid. If it's visible on the wire, and it
changes the visible behaviour of the file server, then it needs
to get documented.

Jeremy.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Bill Wesse]

Jeremy, I agree with you concerning Windows behavior needing to be documented; 
but I felt it necessary to mention the possibilities concerning further 
elaboration - since I am not the one to make that decision (nor do I wish to 
second guess those who do).

My next step is to finish tracking down file handle visibility within the 
server, and how that applies to pass-through versus no pass-through: as you 
noted, there are certainly differences, the main one concerning why 
pass-through doesn't honor the share mode.

My first take on this is to assume pass-through obtains the existing handle 
(making it safe to set the size); but I have not yet confirmed this (or proven 
it wrong - in which case I would be intensely bothered by the behavior, which 
would have the implication of corrupting the state of file state under the 
original handle).

Either way, I do intend to file a TDI on the topic, once I finish the code 
study; I also intend to set up test code to exercise the information levels 
against the SMB calls.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606

-Original Message-
From: Jeremy Allison [mailto:j...@samba.org] 
Sent: Wednesday, November 25, 2009 1:46 PM
To: Bill Wesse
Cc: Tim Prouty; p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation 
is not enforcing share modes

On Wed, Nov 25, 2009 at 05:14:26PM +, Bill Wesse wrote:
> Hello Tim. I think the difference in the response between the standard versus 
> pass-through level lies in how the file handle is obtained during the call 
> (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). 
> The logical conclusion from the trace is that pass-through gets the existing 
> handle, and the non pass-through value simply fails, because a new handle 
> cannot be opened due to the lack of sharing.
> 
> I will continue my investigation into the details on the differences between 
> the base & pass-through handling, with respect to the file path / handle 
> source. Pass-through is basically implementation dependent, as noted in 
> [MS-FSCC] (reference below), so there is a possibility this may not be 
> further elaborated on in the documents.

That won't wash I'm afraid. If it's visible on the wire, and it
changes the visible behaviour of the file server, then it needs
to get documented.

Jeremy.

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Bill Wesse]

Question:

Which existing handle would the pass-through be using?  The handle
opened in packet #28 is a separate tcp connection and a separte
session from the Trans2SetPathInfo in packet #33.  I'm not aware of
any situation where the server is expected to share file handles
across multiple sessions.  Is this an exception?

Response:

I was paying more attention to the PID (0x26CD) - and didn't drill down closer 
to the sessions (both of which use the same security principal). Thanks for 
pointing that out; I will take it into account during my ongoing study (this 
implies a straight share mode bypass).

Question:

If a client can send a particular info level and windows implements
it, then we have a compatibility problem if we choose not to support
it.  What I would really like to know is if other SMB implementations
need to circumvent share-mode checks for this pass through level (and
maybe others?).

Response:

That is certainly one of my goals - as I noted in my recent response to Jeremy, 
I intend to set up test code to exercise the information levels against the SMB 
calls.

As I also mentioned, I will submit a TDI against this - before starting on any 
test code.

Also, the best reference for the full roster of info levels is at:

MSDN WDF_FILE_INFORMATION_CLASS
http://msdn.microsoft.com/en-us/library/dd568296.aspx

this being a subset:
[MS-FSCC] 2.4 File Information Classes
http://msdn.microsoft.com/en-us/library/cc232064.aspx

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606


-Original Message-
From: Tim Prouty [mailto:tim.pro...@isilon.com] 
Sent: Wednesday, November 25, 2009 1:21 PM
To: Bill Wesse
Cc: cifs-proto...@samba.org; p...@tridgell.net
Subject: Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing 
share modes

Hi Bill,

Thank you for the quick answer!  I have a few comments/questions below.

On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote:

> Hello Tim. I think the difference in the response between the  
> standard versus pass-through level lies in how the file handle is  
> obtained during the call (given that TRANS2_SET_PATH_INFORMATION  
> passes the path, and not the handle). The logical conclusion from  
> the trace is that pass-through gets the existing handle, and the non  
> pass-through value simply fails, because a new handle cannot be  
> opened due to the lack of sharing.


Which existing handle would the pass-through be using?  The handle
opened in packet #28 is a separate tcp connection and a separte
session from the Trans2SetPathInfo in packet #33.  I'm not aware of
any situation where the server is expected to share file handles
across multiple sessions.  Is this an exception?


> I will continue my investigation into the details on the differences  
> between the base & pass-through handling, with respect to the file  
> path / handle source. Pass-through is basically implementation  
> dependent, as noted in [MS-FSCC] (reference below), so there is a  
> possibility this may not be further elaborated on in the documents.


If a client can send a particular info level and windows implements
it, then we have a compatibility problem if we choose not to support
it.  What I would really like to know is if other SMB implementations
need to circumvent share-mode checks for this pass through level (and
maybe others?).


> Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a  
> pass-through value), since that requires the file handle (per [MS- 
> CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at 
> http://msdn.microsoft.com/en-us/library/ee442064.aspx) 
> .


I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the
same session would have succeeded.

-Tim

___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[cifs-protocol] SMBv1 LockAndX return status on lock conflict

[Steven Danneman]

Hello,

 

When requesting a byte-range lock over SMBv1 on a range of a file which
is already locked and thus will contend, the error code returned is
inconsistent.  The first attempt to acquire a held lock will return
STATUS_LOCK_NOT_GRANTED.  Subsequent requests will return
STATUS_FILE_LOCK_CONFLICT.

 

This seems as though it may be an error in the implementation of the
SMBv1 protocol as the explanation of the two errors in MS-ERREF implies
that STATUS_LOCK_NOT_GRANTED should always be returned in this
circumstance:

 

STATUS_LOCK_NOT_GRANTED  A requested file lock cannot be
granted due to other existing locks.

STATUS_FILE_LOCK_CONFLICT   A requested read/write cannot be
granted due to a conflicting file lock.

 

And in this same scenario the SMBv2 protocol always returns
STATUS_LOCK_NOT_GRANTED.

 

I aware this is a well known issue, as the Samba torture test
demonstrating this behavior have existed for a number of years, but I
haven't found any Microsoft documentation describing the semantics of
this behavior.  I've looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA.

 

Furthermore, which error code is returned becomes even more complicated
when additional lock requests are interspersed.  For example the
attached pcap against a W2K8R2 server shows:

 

1) Two file handles opened to the same file 0x400b, 0x400c

2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock
on range 100 - 110

3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held
range and receiving STATUS_LOCK_NOT_GRANTED

4) Packet 33-44: Again requesting the same held range and receiving
STATUS_FILE_LOCK_CONFLICT

5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and
receiving the same pattern of errors

6) Packet 55-64: Requesting a lock on the previous range, 100-110, and
now having the response be "reset" back to STATUS_LOCK_NOT_GRANTED

 

I'd like to have some documentation of the algorithm for determining
which error to return based on the state of existing locks, or history
of previously requested locks.

 

Thanks,

Steven Danneman | Software Development Engineer
Isilon SystemsP +1-206-315-7500 F  +1-206-315-7501
www.isilon.com

How breakthroughs begin. (tm)

<>

file_lock_conflict.pcap
Description: file_lock_conflict.pcap
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

Re: [cifs-protocol] SMBv1 LockAndX return status on lock conflict

[Tom Jebo]

Hi Steven,

Thanks for your question regarding SMBv1 LockAndX.  One of the Open 
Specification Documentation team will be in touch with you soon.

Best regards,
Tom Jebo
Open Specification Documentation Support

From: Steven Danneman [mailto:steven.danne...@isilon.com]
Sent: Wednesday, November 25, 2009 6:54 PM
To: Interoperability Documentation Help; cifs-proto...@samba.org; 
p...@tridgell.net
Subject: SMBv1 LockAndX return status on lock conflict

Hello,

When requesting a byte-range lock over SMBv1 on a range of a file which is 
already locked and thus will contend, the error code returned is inconsistent.  
The first attempt to acquire a held lock will return STATUS_LOCK_NOT_GRANTED.  
Subsequent requests will return STATUS_FILE_LOCK_CONFLICT.

This seems as though it may be an error in the implementation of the SMBv1 
protocol as the explanation of the two errors in MS-ERREF implies that 
STATUS_LOCK_NOT_GRANTED should always be returned in this circumstance:

STATUS_LOCK_NOT_GRANTED  A requested file lock cannot be granted 
due to other existing locks.
STATUS_FILE_LOCK_CONFLICT   A requested read/write cannot be 
granted due to a conflicting file lock.

And in this same scenario the SMBv2 protocol always returns 
STATUS_LOCK_NOT_GRANTED.

I aware this is a well known issue, as the Samba torture test demonstrating 
this behavior have existed for a number of years, but I haven't found any 
Microsoft documentation describing the semantics of this behavior.  I've looked 
in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA.

Furthermore, which error code is returned becomes even more complicated when 
additional lock requests are interspersed.  For example the attached pcap 
against a W2K8R2 server shows:

1) Two file handles opened to the same file 0x400b, 0x400c
2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on 
range 100 - 110
3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and 
receiving STATUS_LOCK_NOT_GRANTED
4) Packet 33-44: Again requesting the same held range and receiving 
STATUS_FILE_LOCK_CONFLICT
5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and 
receiving the same pattern of errors
6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now 
having the response be "reset" back to STATUS_LOCK_NOT_GRANTED

I'd like to have some documentation of the algorithm for determining which 
error to return based on the state of existing locks, or history of previously 
requested locks.

Thanks,

Steven Danneman | Software Development Engineer
Isilon SystemsP +1-206-315-7500 F  +1-206-315-7501
www.isilon.com

[cid:image001.gif@01C81005.1792D9C0]   How breakthroughs begin. (tm)
<>___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol