Bug 5128 - readdir returns wrong names in some cases
Summary: readdir returns wrong names in some cases
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.27
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
: 8653 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-06 07:00 UTC by Jonas Hansson (mail bounces back)
Modified: 2017-08-24 18:18 UTC (History)
4 users (show)

See Also:


Attachments
test program (2.42 KB, text/plain)
2007-12-06 07:05 UTC, Jonas Hansson (mail bounces back)
no flags Details
Proposed patch (1.16 KB, patch)
2010-02-21 15:05 UTC, Holger Hetterich
hhetter: review? (jra)
Details
screenshot (51.54 KB, image/png)
2010-02-22 15:14 UTC, Björn Jacke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Hansson (mail bounces back) 2007-12-06 07:00:42 UTC
Tested on version 3.0.27a to be exact, could not find it in the list.
I'm not sure wether this should be in libsmbclient category as this also applies to smbd.

$ cd ~/testdir
$ mkdir "john \"ripper\" doe"
$ touch test.txt
$ ls
john "ripper" doe/  test.txt


the attached program when set to print contents of that dir will output:

smb://192.168.1.203/jonas/testdir
<DIR>   name: .                             decoded: .
<DIR>   name: ..                            decoded: ..
<DIR>   name: JSD7I4%7EK                    decoded: JSD7I4~K
<FILE>  name: test.txt                      decoded: test.txt

"name" is the urlencoded version, "decoded" is the decoded version.
As you can see the file name called "john \"ripper\" doe" is called something completely different and when trying to open that directory it will return with errno set to ENOENT.
When I browse that share/directory from a Windows client I get the same name (JSD7I4~K) and I cannot enter it.
Comment 1 Jonas Hansson (mail bounces back) 2007-12-06 07:05:41 UTC
Created attachment 3023 [details]
test program

Hard coded IP, username, password and sharename, modify it to suit your needs if you want to try it.
Comment 2 Derrell Lipman 2007-12-12 21:06:49 UTC
This is a server issue, not libsmbclient.  The problem is reproducible from a Windows box.
Comment 3 Holger Hetterich 2010-02-21 14:48:55 UTC
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx

"... Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following:

    * The following reserved characters:
          o < (less than)
          o > (greater than)
          o : (colon)
          o " (double quote)
          o / (forward slash)
          o \ (backslash)
          o | (vertical bar or pipe)
          o ? (question mark)
          o * (asterisk)
..."

So "john \"ripper\" doe" would not be a legal filename.
Comment 4 Holger Hetterich 2010-02-21 15:05:38 UTC
Created attachment 5410 [details]
Proposed patch

But should'nd we check if a filename is legal before we try to mangle it?
Jeremy, can you please check?
Comment 5 Holger Hetterich 2010-02-21 15:07:43 UTC
Above patch will make illegal filenames disappear completely to the clients.
Comment 6 Holger Hetterich 2010-02-21 15:14:04 UTC
patch is for master
Comment 7 Jeremy Allison 2010-02-22 12:04:13 UTC
Have you tested this against a Windows server ? I'd believe an smbtorture test much more than I'd believe an MSDN doc I'm afraid.

Jeremy.
Comment 8 Björn Jacke 2010-02-22 15:14:20 UTC
Created attachment 5411 [details]
screenshot

i guess the docs are more or less an advice not to use them. Explorer may also prevent users from creating files like that. The screenshot shows that those characters *are* alloed on NTFS.
Comment 9 Holger Hetterich 2010-02-22 16:02:28 UTC
Ok, sorry. I was under the impression that MSDN docs are valid.
Comment 10 Jeremy Allison 2010-02-22 16:09:31 UTC
Well they're a guide Holger, but only a guide :-). We need to confirm everything they "claim" with torture tests against the latest Windows release :-).

Jeremy.
Comment 11 Björn Jacke 2010-02-23 13:13:44 UTC
actually while taking a look into the initially reported problem I now think that Holger's patch is actually correct. The files I created on the NTFS volume (hacked on it via ntfs-3g :-) are "view-only" and not accessable in any way. One can not even rename or delete them on a XP machine. Accessing a file called a:foo triggers read trys on a floppy drive and so on. Interesting things happen :-)

Finally I think it's perfectly valid to mangle these filenames for non-unix clients. hash2 already acts like this, Holger's patch addresses hash the same way. Jeremy, do you agree?
Comment 12 Björn Jacke 2010-02-23 13:17:26 UTC
err, what patch did I look at, that one addesses hash2.

Anyway, to hash the filenames seems to be the right thing to do.
Comment 13 Holger Hetterich 2010-02-24 06:50:40 UTC
Blörn, I was just backtracing what happens when I use the same procedure as the reporter described, and just found it goes into hash2. I did not even knew about hash.
Comment 14 Holger Hetterich 2010-03-05 14:16:15 UTC
I am not sure how we go on here.

As Björn describes in comment #11, those filenames are indeed illegal under windows. One cannot do any file system operation with them, and they lead to unkown effects.

Therefore I still think my patch has at least some points.

You can create such a filename through linux only, for example smbclient will not allow to create such a filename.
Comment 15 Björn Jacke 2017-08-24 18:18:24 UTC
*** Bug 8653 has been marked as a duplicate of this bug. ***