[PATCH] CIFS: add SFM mapping for 0x01-0x1F

[PATCH] CIFS: add SFM mapping for 0x01-0x1F

[Björn JACKE]

[-- Attachment #1.1: Type: text/plain, Size: 154 bytes --]

Hi,

attached patch adds more missing mappings for the 0x01-0x1f range. Please
review, if you're fine with it, considere it also for stable.

Björn

[-- Attachment #1.2: 0001-cifs-add-SFM-mapping-for-0x1-0x20.patch --]
[-- Type: text/x-diff, Size: 1254 bytes --]

From a97720c26db2ee77d4e798e3d383fcb6a348bd29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Jacke?= <bjacke-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Date: Wed, 31 May 2017 22:48:41 +0200
Subject: [PATCH] cifs: add SFM mapping for 0x01-0x1F

0x1-0x1F has to be mapped to 0xF001-0xF01F

Signed-off-by: Bjoern Jacke <bjacke-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
---
 fs/cifs/cifs_unicode.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c
index a0b3e7d..e0445e2 100644
--- a/fs/cifs/cifs_unicode.c
+++ b/fs/cifs/cifs_unicode.c
@@ -79,6 +79,10 @@ convert_sfu_char(const __u16 src_char, char *target)
 static bool
 convert_sfm_char(const __u16 src_char, char *target)
 {
+	if (src_char >= 0xF001 && src_char <= 0xF01F) {
+		*target = src_char - 0xF000;
+		return true;
+	}
 	switch (src_char) {
 	case SFM_COLON:
 		*target = ':';
@@ -417,6 +421,10 @@ static __le16 convert_to_sfm_char(char src_char, bool end_of_string)
 {
 	__le16 dest_char;
 
+	if (src_char >= 0x01 && src_char <= 0x1F) {
+		dest_char = cpu_to_le16(src_char + 0xF000);
+		return dest_char;
+	}
 	switch (src_char) {
 	case ':':
 		dest_char = cpu_to_le16(SFM_COLON);
-- 
2.7.4


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] CIFS: add SFM mapping for 0x01-0x1F

[Aurélien Aptel]

Hi Björn,

Are these mappings documented somewhere? Now that Windows has a new
Linux subsystem I wonder if any of these SFM/SFU mappings have changed.

Cheers,

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [PATCH] CIFS: add SFM mapping for 0x01-0x1F

[Björn Jacke]

[-- Attachment #1.1: Type: text/plain, Size: 617 bytes --]

Hi Aurélien,
On 01.06.2017 11:31, Aurélien Aptel wrote:
> Are these mappings documented somewhere? Now that Windows has a new
> Linux subsystem I wonder if any of these SFM/SFU mappings have changed.
> 
> Cheers,
> 

it once was documentd in MS KB117258 ... which disappeared
unfortunately, wayback machine still has is though:

https://web-beta.archive.org/web/20150315001238/http://support.microsoft.com:80/en-us/kb/117258

I also verified that current OS X clients use these mappings for SMB.

The only remaining mapping which needs fixing in the cifs module is the
backslash now.

Björn



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] CIFS: add SFM mapping for 0x01-0x1F

[Steve French]

merged into cifs-2.6.git

JRA had some security concerns about allowing \ mapping so we need to
be careful in deciding how we want Samba to handle that too

On Thu, Jun 1, 2017 at 5:04 AM, Björn Jacke <bjacke-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> Hi Aurélien,
> On 01.06.2017 11:31, Aurélien Aptel wrote:
>> Are these mappings documented somewhere? Now that Windows has a new
>> Linux subsystem I wonder if any of these SFM/SFU mappings have changed.
>>
>> Cheers,
>>
>
> it once was documentd in MS KB117258 ... which disappeared
> unfortunately, wayback machine still has is though:
>
> https://web-beta.archive.org/web/20150315001238/http://support.microsoft.com:80/en-us/kb/117258
>
> I also verified that current OS X clients use these mappings for SMB.
>
> The only remaining mapping which needs fixing in the cifs module is the
> backslash now.
>
> Björn
>
>



-- 
Thanks,

Steve

Re: SFM mapping of \

[Björn Jacke]

Hi,

On 28.06.2017 07:02, Steve French wrote:
> JRA had some security concerns about allowing \ mapping so we need to
> be careful in deciding how we want Samba to handle that too

I don't really see how the cifs client-side mapping of the "\" character
should affect Samba security here. The client only maps "\" to an
innocent unicode character. The server does nothing with that unicode
character at all. It just stores it as it is - unless you configure via
vfs fruit that you want to convert it to native encoding. But that's
actually nothing that cifs vfs has to worry about. Even without an our
mapping of "\" we can simply create unicode 0xF021 now on a remote SMB
server. And the smb mac clients already do it anyway.

Björn