[cifs-protocol] [EXTERNAL] Re: SMB2_CREATE pathname "x\..\y.txt" -> STATUS_INVALID_PARAMETER? [120061624003369]
Jeff McCashland
jeffm at microsoft.com
Wed Jun 17 17:26:12 UTC 2020
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
More information about the cifs-protocol
mailing list