Bug 973 - RAP NetShareEnum() not filtering long share names.
RAP NetShareEnum() not filtering long share names.
Product: Samba 3.0
Classification: Unclassified
Component: File Services
All All
: P3 normal
: none
Assigned To: Christophuzzy R. Hertel
Depends on:
  Show dependency treegraph
Reported: 2004-01-14 22:43 UTC by Christophuzzy R. Hertel
Modified: 2005-08-24 10:18 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Christophuzzy R. Hertel 2004-01-14 22:43:29 UTC
Windows 9x and Me use the old RAP calls.  In particular, they use
NetShareEnum() RAP call to retrieve share names.  NetShareEnum() has a
built-in share name limit of 12 bytes.  If you send a NetShareEnum()
request to a W2K server that has a share named "verylongsharename" that
share won't be listed.

What I'm seeing from the latest CVS is that the name "verylongshare" is
returned and displayed (by W98 in this case).  There are two problems with
the above name:
  1) It's truncated, so it's not the correct share name and the share
     cannot be accessed.
  2) It's 13 characters.  That means that we're not terminating the
     string.  No terminating nul byte!

Testing against W2K I confirmed that it won't return share names longer
than 12 bytes (not even names that are exactly 13 bytes), and the names
that are returned are always nul-terminated.

So, somewhere in lanman.c (need to look a little closer) we need to be
checking the name length and skipping the name if it's longer than 12
Comment 1 Christophuzzy R. Hertel 2004-01-28 15:11:17 UTC
The fix I've applied to HEAD is based on Simo's patch, which skips any name
longer than 12 bytes.  This is compatible with what Windows does.

A better fix would be to do a simple name mangling (*not* based on existing
mangling code) to create 12-character names from long share names, and store
both.  Return the long name in response to the RPC call, and return the short
name in response to the RAP call.

I want a simpler mangling algorithm because I'd like to preserve as much of the
original name as possible.  So, something like this, perhaps:


etc., using a minimum of hex digits for the part after the tilde.

...just a thinkling.
Comment 2 Christophuzzy R. Hertel 2004-01-29 12:28:18 UTC
Jeremy merged the changes into 3.0.
Comment 3 Christophuzzy R. Hertel 2004-01-29 13:02:53 UTC
Closing this one out.
Comment 4 Gerald (Jerry) Carter 2005-08-24 10:18:13 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.