[PATCH][SMB3] allow files to be created with backslash in file name
smfrench at gmail.com
Sun Jan 3 00:19:39 UTC 2021
I agree with the idea of being safe (in the smbclient in this case),
and not returning potentially dangerous file names (even if a very
remote danger to the tool, smbclient in this case), but I am not
convinced that the "user friendly" behavior is to reject the names
with the rather confusing message - especially as it would mean that
inserting a single file with an odd name into a server could make the
whole share unusable for smbclient (e.g. in a backup scenario). I
agree with rejecting (or perhaps better skipping) it, but ... not sure
any user would understand what SMBecho has to do with a server file
"NT_STATUS_INVALID_NETWORK_RESPONSE listing \*
smb: \> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The
connection is disconnected now"
On Fri, Jan 1, 2021 at 11:25 PM Jeremy Allison <jra at samba.org> wrote:
> On Fri, Jan 01, 2021 at 09:49:06PM -0600, Steve French wrote:
> >I exported the /scratch directory with smb.conf configured as
> > 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.
More information about the samba-technical