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 name. "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@xxxxxxxxx> wrote: > > 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. -- Thanks, Steve
