[cifs-protocol] [EXTERNAL] Re: SMB2_CREATE pathname "x\..\y.txt" -> STATUS_INVALID_PARAMETER? [120061624003369]

[Jeff McCashland]

Hi Volker,

I will be raising the issue with the content team to consider documenting the behavior. 

Please let me know if you have further concerns. 

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475

-----Original Message-----
From: Volker Lendecke <Volker.Lendecke at SerNet.DE> 
Sent: Tuesday, June 16, 2020 4:13 PM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: [EXTERNAL] Re: SMB2_CREATE pathname "x\..\y.txt" -> STATUS_INVALID_PARAMETER? [120061624003369]

On Tue, Jun 16, 2020 at 11:07:18PM +0000, Jeff McCashland wrote:
> You found some interesting code that I did not find documentation for. 
> However, it is necessary to violate the spec in order to hit it, so it 
> isn't something we would document.
> 
> Please note:
> [FSCC]
> 2.1.5 Pathname
> 2.1.5.1	Dot Directory Names
> Except where explicitly permitted, a pathname component that is a dot 
> directory name MUST NOT be sent over the wire.

Yep, I know that snippet. My problem is that this does not document that doing this leads to INVALID_PARAMETER and not INVALID_OBJECT_NAME or some other error message.

> That being said, Windows Server parses the filename after the check 
> for DFS normalization, and attempts to remove/resolve any "." or ".." 
> references in order to reduce the buffer size. If it finds "\..\", it 
> searches the string before that point for an earlier "\"
> separator to find the parent directory. In the test you mentioned for 
> "x\..\y.txt", there is no earlier separator. When this routine fails, 
> it returns INVALID_PARAMETER. Note that an open to "x\y\..\z.txt" 
> would not fail this routine (but it is still a violation, so might 
> fail otherwise).

I'll try that, thanks for the hint.

> Please let me know if you have further concerns on this issue. 

Well, I would have thought that any behaviour visible on the network would be documented in the spec, but apparently I was wrong...

Thanks,

Volker