Tridge,

  I posted the following  response to your  forum post:   
http://forums.msdn.microsoft.com/en-US/os_fileservices/thread/045900f6-0b9c-4035-9477-857a2ae9ef1a/


    Hi, Tridge,

   Thanks for posing the question.    As the result of  our investigation,  the 
rules of validations enforced by Windows servers are as follows.



1.       An SMB1 file name MUST conform to the following guidance:


*         The path MUST conform to the format described in CIFS section [3.2]

*         Multiple separator characters between elements is allowed.  (i.e. 
directory\\\file)

*         Leading separator characters are allowed (i.e. both directory\file 
and \directory\file are legal)

*         Ending separator characters are allowed (i.e. "directory" and 
"directory\" are allowed)

*         "." is allowed in a path to indicate the current directory.  
(\directory\.\file == \directory\file)

*         ".." is allowed to indicate a parent path as long as the path does 
not escape the root of the share.  If the ".." would move above the root of the 
share, the request MUST be failed with STATUS_OBJECT_PATH_SYNTAX_BAD.

*         If the dialect is not NTLM 0.12:

a.       Trailing spaces MUST be removed from the name.

b.      Trailing "."'s MUST be removed from the name.



2.       An SMB2 file name MUST conform to the following guidance:


*         If the path beings with a separator character ('\'), the request MUST 
be failed with STATUS_INVALID_OBJECT_NAME.

*         If the path contains multiple separator characters between elements, 
the request MUST be failed with STATUS_INVALID_OBJECT_NAME.

*         Ending separator characters  are allowed.

*         Each element in the path must be no more than 255 characters.

         The rules and error behaviors described above will be added to 
[MS-SMB] and [MS-SMB2].    We are finalizing the changes to the documents and 
will post them when  they are available.   Please don't hesitate to let us know 
if you think that more information is needed.


         Thanks

          Hongwei Sun -MSFT





-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2008 10:21 PM
To: Sebastian Canevari
Cc: Interoperability Documentation Help; [EMAIL PROTECTED]
Subject: Re: Create Access Mask



Hi Sebastian,



 > I was wondering if you were able to review the information that I

 > provided to you about the matter.



sorry for the slow reply, I've been a bit busy at the plugfest this

week.



 > I've been reviewing the info on the document and I would need a little 
 > clarification from you.

 >

 >  The mask that you are using 0D F0 FE 00, includes one bit that's described 
 > on the document (ACCESS_SYSTEM_SECURITY 0x01000000).

 >

 >  It's not clear to us that you need this mask. Can you clarify what you're 
 > doing that you need it or I'd suggest dropping the bit from the mask as I 
 > state next...

 >

 > If not, I would suggest to run your test with the following mask:  0C F0 FE 
 > 00



The test sends a separate SMB2 CREATE request for each bit, so it

sends 32 separate CREATE calls. Have a look at this capture:



  http://samba.org/~tridge/smb2_create_vista.cap



Start at frame 33. There you see it trying a create with a access_mask

of 1. Then at frame 37 it tries it with an access_mask of 2, and so on

up to frame 129 where 0x80000000 is tried.



The test put together all the single bits that give ACCESS_DENIED or

PRIVILEGE_NOT_HELD, and gets this mask 0x0df0fe00.



Many of these bits are not explained in 2.2.13.1 of MS-SMB2, but if

they return ACCESS_DENIED or PRIVILEGE_NOT_HELD then that indicates

they are not ignored, and must have some meaning.



So, I think you need to document what the meaning of the bits in

0x0df0fe00 that are not in the table in 2.2.13.1 mean. Some of them

are documented (as you noticed, 0x01000000 is documented), but many of

them aren't. They all should be.



Cheers, Tridge


_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to