Re: [PATCH][SMB3] allow files to be created with backslash in file name

[Jeremy Allison <jra@samba.org>]

On Fri, Jan 01, 2021 at 09:49:06PM -0600, Steve French wrote:
>I exported the /scratch directory with smb.conf configured as
>
>[scratch]
>   comment = scratch share for testing
>   browseable = yes
>   path = /scratch
>   guest ok = yes
>   read only = no
>   ea support = yes
>   create mask = 0777
>   directory mask = 0777
>   vfs objects = acl_xattr
>   map acl inherit = yes
>   strict allocate = yes
>   map acl inherit = yes
>   mangled names = no
>
>Connecting with smbclient and doing a simple ls causes the disconnect:
>$ smbclient --version
>Version 4.12.5-Ubuntu
>$ smbclient //localhost/scratch -U testuser
>Enter SAMBA\testuser's password:
>Try "help" to get a list of possible commands.
>smb: \> ls
>  .                                   D        0  Fri Jan  1 21:19:52 2021
>  ..                                  D        0  Thu Dec 31 21:42:28 2020
>  rsvd-chars                          D        0  Fri Jan  1 09:14:04 2021
>  file-?-question                     N        0  Fri Jan  1 21:19:42 2021
>is_bad_finfo_name: bad finfo->name
>NT_STATUS_INVALID_NETWORK_RESPONSE listing \*
>smb: \> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The
>connection is disconnected now

Well of course it disconnects. You set

"mangled names = no"

So the server returns the bad name. The smbclient
library notices the server is trying to screw with
it by sending invalid Windows names and disconnects
to protect itself.

This is by design. There is a *REASON* mangled names = yes
is the default. Otherwise you can't see valid server
filenames that contain : \ etc. etc. from a Windows client.

Even a file names AUX: has to be mangled. "mangled names = no"
is only useful for a pre-cleaned exported file system which
you can guarantee contains only Windows-compatible names.

This is not a bug, it's working as designed to protect
the client code.

There was a CVE where libsmbclient might pass up
names containing a '/' to the calling code (not
that they can exist on disk, but a malicious server
could send them) which might then treat it as a
path separator.