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

Backslash is reserved in Windows (and SMB2/SMB3 by default) but
allowed in POSIX so must be remapped when POSIX extensions are
not enabled.

The default mapping for SMB3 mounts ("SFM") allows mapping backslash
(ie 0x5C in UTF8) to 0xF026 in UCS-2 (using the Unicode remapping
range reserved for these characters), but this was not mapped by
cifs.ko (unlike asterisk, greater than, question mark etc).  This patch
fixes that to allow creating files and directories with backslash
in the file or directory name.

Before this patch:
   touch "/mnt2/filewith\slash"
would return
   touch: setting times of '/mnt2/filewith\slash': Invalid argument

With the patch touch and mkdir with the backslash in the name works.

This problem was found while debugging xfstest 453 - see
    https://bugzilla.kernel.org/show_bug.cgi?id=210961

This patch may be even more important to Samba, as alternative ways of
storing these files can create more problems. Interestingly Samba
server reports local files with backslashes in them over the wire
without remapping, even though these are illegal in SMB3 which would
cause confusion on the client(s).  Has anyone tried Windows mounting
to Samba and viewing files with locally created Linux files that
include these reserved characters (presumably Windows clients won't
like it either)?

This patch does allow creating/viewing files with remotely with '\' in
the file name from Linux (cifs.ko) but does not completely fix xfstest
453 kernel (more investigation of this test is needed).  Test 453
creates filenames with 'horrifying'
(using their term) sequences of arbitrary bytes in file names.

Reported-by: Xiaoli Feng <xifeng@redhat.com>

On Thu, Dec 31, 2020 at 09:35:23PM -0600, Steve French via samba-technical wrote:
>
>This patch may be even more important to Samba, as alternative ways of
>storing these files can create more problems. Interestingly Samba
>server reports local files with backslashes in them over the wire
>without remapping, even though these are illegal in SMB3 which would
>cause confusion on the client(s).  Has anyone tried Windows mounting

Samba should mangle names containing '\' to 8.3 names.

The code in is_legal_name() should catch names containing
'\' and report them as needing mapping to 8.3.

Indeed if I check this locally with smbclient I get
(for a share containing a file created with:

$ touch 'file with \ in it'

I see the file:

FI32YH~P

listed from smbclient -mSMB3

Check how you have Samba configured Steve.

On Fri, Jan 01, 2021 at 09:12:14AM -0600, Steve French wrote:
>On Fri, Jan 1, 2021 at 12:00 AM Jeremy Allison <jra@samba.org> wrote:
>>
>> On Thu, Dec 31, 2020 at 09:35:23PM -0600, Steve French via samba-technical wrote:
>> >
>> >This patch may be even more important to Samba, as alternative ways of
>> >storing these files can create more problems. Interestingly Samba
>> >server reports local files with backslashes in them over the wire
>> >without remapping, even though these are illegal in SMB3 which would
>> >cause confusion on the client(s).  Has anyone tried Windows mounting
>>
>> Samba should mangle names containing '\' to 8.3 names.
>
>You were right mangled names was enabled.  But that is also
>interesting - it does expose a bug in smbclient.
>
>When you connect smbclient - doing a ls of a subdirectory with
>reserved characters worked, but doing an ls of the parent (root
>directory of share) caused smbclient to disconnect.  See below
>
>smb: \> ls rsvd-chars
>  rsvd-chars                          D        0  Fri Jan  1 08:55:49 2021
>
>556368460 blocks of size 1024. 296010296 blocks available
>smb: \> ls
>  .                                   D        0  Fri Jan  1 08:54:28 2021
>  ..                                  D        0  Thu Dec 31 21:42:28 2020
>  topdir                              D        0  Mon Dec 14 16:01:25 2020
>  lock1.txt                           A      200  Fri Dec 18 12:28:18 2020
>  lock_rw_shared.dat                  A      200  Fri Dec 18 12:28:18 2020
>  lock_rw_exclusive.dat               A      200  Fri Dec 18 12:28:18 2020
>  autounlock.txt                      A      200  Fri Dec 18 12:28:18 2020
>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

Can you log a bug please and give full setup instructions
to reproduce. This isn't enough to show me what the bug is.
I need a directory listing from the Server side to show
me what files are in the root of the share.

Also, you neglect to tell me what Samba version you are
using (which is a pre-requisite for a bug report Steve,
you know this :-).

On Fri, Jan 01, 2021 at 09:12:14AM -0600, Steve French wrote:
>On Fri, Jan 1, 2021 at 12:00 AM Jeremy Allison <jra@samba.org> wrote:
>>
>> On Thu, Dec 31, 2020 at 09:35:23PM -0600, Steve French via samba-technical wrote:
>> >
>> >This patch may be even more important to Samba, as alternative ways of
>> >storing these files can create more problems. Interestingly Samba
>> >server reports local files with backslashes in them over the wire
>> >without remapping, even though these are illegal in SMB3 which would
>> >cause confusion on the client(s).  Has anyone tried Windows mounting
>>
>> Samba should mangle names containing '\' to 8.3 names.
>
>You were right mangled names was enabled.  But that is also
>interesting - it does expose a bug in smbclient.
>
>When you connect smbclient - doing a ls of a subdirectory with
>reserved characters worked, but doing an ls of the parent (root
>directory of share) caused smbclient to disconnect.  See below
>
>smb: \> ls rsvd-chars
>  rsvd-chars                          D        0  Fri Jan  1 08:55:49 2021
>
>556368460 blocks of size 1024. 296010296 blocks available
>smb: \> ls
>  .                                   D        0  Fri Jan  1 08:54:28 2021
>  ..                                  D        0  Thu Dec 31 21:42:28 2020
>  topdir                              D        0  Mon Dec 14 16:01:25 2020
>  lock1.txt                           A      200  Fri Dec 18 12:28:18 2020
>  lock_rw_shared.dat                  A      200  Fri Dec 18 12:28:18 2020
>  lock_rw_exclusive.dat               A      200  Fri Dec 18 12:28:18 2020
>  autounlock.txt                      A      200  Fri Dec 18 12:28:18 2020
>is_bad_finfo_name: bad finfo->name
>NT_STATUS_INVALID_NETWORK_RESPONSE listing \*

This is coming from the following code which is designed to
protect the client from a malicious server returning a '\' or '/'
character in an filename component.

/****************************************************************************
  Check if a returned directory name is safe.
****************************************************************************/

static NTSTATUS is_bad_name(bool windows_names, const char *name)
{
         const char *bad_name_p = NULL;

         bad_name_p = strchr(name, '/');
         if (bad_name_p != NULL) {
                 /*
                  * Windows and POSIX names can't have '/'.
                  * Server is attacking us.
                  */
                 return NT_STATUS_INVALID_NETWORK_RESPONSE;
         }
         if (windows_names) {
                 bad_name_p = strchr(name, '\\');
                 if (bad_name_p != NULL) {
                         /*
                          * Windows names can't have '\\'.
                          * Server is attacking us.
                          */
                         return NT_STATUS_INVALID_NETWORK_RESPONSE;
                 }
         }
         return NT_STATUS_OK;
}

On Fri, Jan 01, 2021 at 05:57:08PM -0500, Steve French wrote:
>4.12.4 Ubuntu
>
>On Fri, Jan 1, 2021, 14:58 Jeremy Allison <jra@samba.org> wrote:
>> >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
>>
>> Can you log a bug please and give full setup instructions
>> to reproduce. This isn't enough to show me what the bug is.
>> I need a directory listing from the Server side to show
>> me what files are in the root of the share.
>>
>> Also, you neglect to tell me what Samba version you are
>> using (which is a pre-requisite for a bug report Steve,
>> you know this :-).

To channel Rowland, this isn't a bug report, this is an
anecdote :-).

Here's what I did to show this doesn't happen.

$ mkdir /tmp/chartest
$ touch /tmp/chartest/fil\\e.dat
$ ls -l /tmp/chartest/
total 0
-rw-rw-r-- 1 user user 0 Jan  1 18:52 'fil\e.dat'

Edit /usr/local/samba/etc/smb.conf, add:

[chartest]
	path = /tmp/chartest
	guest ok = yes
	read only = no

Restart smbd. Run:

$ /usr/local/samba/bin/smbclient //127.0.0.1/chartest -Uuser%password -mSMB3
smb: \> ls
   .                                   D        0  Fri Jan  1 18:52:10 2021
   ..                                  D        0  Fri Jan  1 18:51:38 2021
   FI7KDO~J.DAT                        N        0  Fri Jan  1 18:52:10 2021

IF YOU WANT ME TO INVESTIGATE THIS IS NEED A SIMILAR
LEVEL OF DETAIL (sigh). But I *know* you *know*
this...

I wasn't able to setup a second independent repro of this until
tonight, but the smbclient behavior (bug) does appear to be dependent
on the version of smbclient (see below).  Newer versions failed
(including current Samba, 4.14-pre and 4.12.5 Ubuntu).  These were all
attempted on the same machine, and the repro was simple. See below.

Recreation:
create two files with reserved characters (locally on the server) in
the root of the share (in this case xfs, running on the current stable
kernel,
5.10.4 although that is unlikely to matter)
$ ls /scratch
'file-\-backslash'  'file-?-question'

I also created a subdirectory with additional files with reserved
characters, although that may not matter.

$ ls /scratch/rsvd-chars
'dir-with-trailing-space '  'file-\backslash'    'file space'
 file                       'file->greaterthan'
'file-*asterisk'            'file-?question'

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

wireshark trace shows a simple open (SMB3.1.1 create) followed by
level 37 SMB3.1.1 find request, then smbclient appears to drop the tcp
session.

Running smbclient with -d 10 (debug level) shows these three messages

dos_clean_name [\*]
unix_clean_name [\*]
is_bad_finfo_name: bad finfo->name

Trying the same thing with *older* smbclient worked, although there is
a possibility that other differences in build with the two smbclients
could be the reason that the older one worked and the newer one
failed:

$ /usr/local/samba/bin/smbclient //localhost/share --version
Version 4.11.0pre1-GIT-e63e391a1ad
$ /usr/local/samba/bin/smbclient //localhost/scratch -U testuser
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
  file-\-backslash                    N        0  Fri Jan  1 21:19:52 2021

556368460 blocks of size 1024. 295948832 blocks available

I also tried it with current smbclient and it also failed:

$ ./bin/smbclient --version
Version 4.14.0pre1-DEVELOPERBUILD
$ ./bin/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

On Fri, Jan 1, 2021 at 8:58 PM Jeremy Allison <jra@samba.org> wrote:
>
> On Fri, Jan 01, 2021 at 05:57:08PM -0500, Steve French wrote:
> >4.12.4 Ubuntu
> >
> >On Fri, Jan 1, 2021, 14:58 Jeremy Allison <jra@samba.org> wrote:
> >> >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
> >>
> >> Can you log a bug please and give full setup instructions
> >> to reproduce. This isn't enough to show me what the bug is.
> >> I need a directory listing from the Server side to show
> >> me what files are in the root of the share.
> >>
> >> Also, you neglect to tell me what Samba version you are
> >> using (which is a pre-requisite for a bug report Steve,
> >> you know this :-).
>
> To channel Rowland, this isn't a bug report, this is an
> anecdote :-).
>
> Here's what I did to show this doesn't happen.
>
> $ mkdir /tmp/chartest
> $ touch /tmp/chartest/fil\\e.dat
> $ ls -l /tmp/chartest/
> total 0
> -rw-rw-r-- 1 user user 0 Jan  1 18:52 'fil\e.dat'
>
> Edit /usr/local/samba/etc/smb.conf, add:
>
> [chartest]
>         path = /tmp/chartest
>         guest ok = yes
>         read only = no
>
> Restart smbd. Run:
>
> $ /usr/local/samba/bin/smbclient //127.0.0.1/chartest -Uuser%password -mSMB3
> smb: \> ls
>    .                                   D        0  Fri Jan  1 18:52:10 2021
>    ..                                  D        0  Fri Jan  1 18:51:38 2021
>    FI7KDO~J.DAT                        N        0  Fri Jan  1 18:52:10 2021
>
> IF YOU WANT ME TO INVESTIGATE THIS IS NEED A SIMILAR
> LEVEL OF DETAIL (sigh). But I *know* you *know*
> this...

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.

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@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
> >
> >[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.

On Sat, Jan 02, 2021 at 06:19:39PM -0600, Steve French wrote:
>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.

Dropping the connection on receipt of an invalid
name is the only safe response. We know the server
is insane and dangerous at that point and sending
invalid protocol responses.

Safer not to continue.

>"NT_STATUS_INVALID_NETWORK_RESPONSE listing \*
>smb: \> SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The
>connection is disconnected now"

The SMBecho is due to the keepalive failing once
the connection was dropped.

On Sat, Jan 02, 2021 at 05:21:16PM -0800, Jeremy Allison via samba-technical wrote:
>On Sat, Jan 02, 2021 at 06:19:39PM -0600, Steve French wrote:
>>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

FYI, as I pointed out this only happens if you *explicitly*
set a server parameter that is only expected to be set on
a share with "clean" (no non-Windows) names.

So just creating a file containing : \ etc. doesn't do
this - you have to misconfigure the server FIRST.

On Sat, Jan 2, 2021 at 7:25 PM Jeremy Allison <jra@samba.org> wrote:
>
> On Sat, Jan 02, 2021 at 05:21:16PM -0800, Jeremy Allison via samba-technical wrote:
> >On Sat, Jan 02, 2021 at 06:19:39PM -0600, Steve French wrote:
> >>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
>
> FYI, as I pointed out this only happens if you *explicitly*
> set a server parameter that is only expected to be set on
> a share with "clean" (no non-Windows) names.
>
> So just creating a file containing : \ etc. doesn't do
> this - you have to misconfigure the server FIRST.

I agree that with Samba server this is less common (not sure how many
vendors set that smb.conf
parm) but note that "man smb.conf" does not warn that disabling name
mangling will break
smbclient (assuming that local files have been created on the server with one of
the various reserved characters, perhaps over NFS for example).  But
... there are many
other servers, and I wouldn't be surprised if other servers have
sometimes returned files
created by NFS or Ceph or some cluster fs that contain reserved
characters, even if
it is illegal.

> The SMBecho is due to the keepalive failing
We (SMB/CIFS developers) would know that, but I doubt that all users
would realize that
(for example) creating a file over NFS with a reserved character and
then reexporting the
file over SMB with Samba configured with managled names off, or with a
server that
is less strict than Samba.   Seems like it would be better to print a
warning like:
                    "exiting due to invalid character found in file name"
rather than killing the session and ending up with the (to most users)
unehelpful error message.

On Sat, Jan 02, 2021 at 09:45:53PM -0600, Steve French wrote:
>> So just creating a file containing : \ etc. doesn't do
>> this - you have to misconfigure the server FIRST.
>
>I agree that with Samba server this is less common (not sure how many
>vendors set that smb.conf

No one sets it by default to my knowledge.

>parm) but note that "man smb.conf" does not warn that disabling name
>mangling will break

Patches to the manpage welcome :-).

>smbclient (assuming that local files have been created on the server with one of
>the various reserved characters, perhaps over NFS for example).  But
>... there are many
>other servers, and I wouldn't be surprised if other servers have
>sometimes returned files
>created by NFS or Ceph or some cluster fs that contain reserved
>characters, even if
>it is illegal.

Sure - but that then becomes a possible CVE for these
filesystem clients if they don't protect themselves
against server attacks.

What does *your* client code do if a server returns a
filename containing a / ? If you pass it up, the upper
layers may screw things up badly.

>> The SMBecho is due to the keepalive failing
>We (SMB/CIFS developers) would know that, but I doubt that all users
>would realize that
>(for example) creating a file over NFS with a reserved character and
>then reexporting the
>file over SMB with Samba configured with managled names off, or with a
>server that
>is less strict than Samba.   Seems like it would be better to print a
>warning like:
>                    "exiting due to invalid character found in file name"
>rather than killing the session and ending up with the (to most users)
>unehelpful error message.

True. Again, patches welcome :-).