[PATCH] s3:loadparm: Ensure to truncate FS Volume Label at multibyte boundary

[Jeremy Allison]

On Tue, May 14, 2019 at 06:26:07PM +0000, Shyam Rathi via samba-technical wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=13947
> 
> 
> To reproduce, create a share with a name where 32nd byte is not the first byte of a mutlibyte character. Using CJK characters (3 bytes each) is a possible approach. For example, creating a share with name 에이에프에스삼점오생성 and trying to open a txt file in Notepad gives the following error:
> 
>   Invalid character. For multibyte character sets, only the leading byte is
>   included without the trailing byte. For Unicode character sets, include
>   the characters 0xFFFF and 0xFFFE.
> 
> Looking at wireshark capture, the following is seen as source of this issue:
> 
>   GetInfo Request FS_INFO/FileFsVolumeInformation File: Rathi9\???????????
>   GetInfo Response, Error: STATUS_ILLEGAL_CHARACTER
> 
> Proposed solution is to truncate the label name at the end of a multibyte character before the 32nd byte.
> 
> Please review and suggest changes, improvements and other approaches.
> 
> Regards,
> -Shyamsunder Rathi (mailto:shyam.rathi at nutanix.com)

Thanks - Shyamsunder, I'll try and get this reviewed asap !

Cheers,

	Jeremy.

> From: Shyam Rathi <shyam.rathi at nutanix.com>
> Date: Tuesday, May 14, 2019 at 10:52 AM
> To: "samba-technical at lists.samba.org" <samba-technical at lists.samba.org>
> Subject: [PATCH] s3:loadparm: Ensure to truncate FS Volume Label at multibyte boundary
> 
> For FS_VOLUME_INFO/FS_INFO operation, a maximum of 32 characters are
> sent back. However, since Samba chops off any share name with >32
> bytes at 32, it is possible that a multi-byte share name can get chopped
> off between a full character. This causes the string decoding for unicode
> failure which sends back NT_STATUS_ILLEGAL_CHARACTER (EILSEQ) to the client
> applications.
> 
> On Windows, Notepad doesn't like it, and refuses to open a file in this
> case and fails with the following error:
> 
>   Invalid character. For multibyte character sets, only the leading byte is
>   included without the trailing byte. For Unicode character sets, include
>   the characters 0xFFFF and 0xFFFE.
> 
> Proposed fix:
> - Find the last starting point of a multibyte codepoint if the character
>   at 32nd byte is a subsequent byte of a MB codepoint.
> 
> Reviewed-by: Hemanth Thummala <mailto:hemanth.thummala at nutanix.com>
> Signed-off-by: Shyamsunder Rathi <mailto:shyam.rathi at nutanix.com>
> 
> 
> Regards,
> 
> -Shyamsunder Rathi (mailto:shyam.rathi at nutanix.com)
> 
> 
>