RAP bug: Not truncating names to 12 characters.

[Christopher R. Hertel]

Whoah, folks.  I think we have a slight problem of everyone being correct
here.  :)

On Sat, Jan 17, 2004 at 01:36:56AM -0500, Michael B Allen wrote:
> 
> > I wasn't saying that bug 767 was this RAP bug -- I was saying that the first
> > part of the bug ab mentioned (smbclient not displaying the names >12 chars)
> > is covered in that bug report.

Right.  The problem is that smbclient will display the 13-byte names that
our NetShareEnum() RAP handling incorrectly returns.  (Okay, that's
twisty.  Let me try again...)

When handling the NetShareEnum() call, Samba should not return names 
longer than 12 bytes.  Instead, names longer than 12 bytes are truncated 
to *13* bytes with no terminating nul byte.  Ouch.

Smbclient and Windows clients (W9x,Me) will display the 13 byte names.
(I'm guessing that there's a bit of defensive programming going on here.)
If the real name actually is 13 bytes, then all of these clients *can*
access the share.

So, in lanman.c we should be filtering out names greater than 12 bytes 
long but in smbclient we should make sure that we can handle longer names 
if we receive them.  ...just in case.

> Nope again :-) If by "ab" you mean Alexader B? he wrote:
> 
> "Same with smbclient. It does display them but can't access. It also has
> bug in that displayed share name is cropped:
> d_printf("\t%-15.15s%-10.10s%s\n", name, typestr, comment);"

If the names we receive are no more than 12 (13) bytes long (plus one for
the nul byte) then 15 bytes should be enough.  When smbclient is updated 
to perform the RPC call this will need to be changed.

> This describes two bugs neither of which relate to 767. The first is the
> "display tuncated share names but can't access" bug in Samba's
> implementation of the NetrShareEnum RAP that Chris reported.

Well, NetShareEnum() (no extra 'r')...but yeah.  If the name is truncated 
then it is, basically, the wrong name.

> The second appears to be some kind of
> printf debug output truncation that is pretty much harmless. These are really
> totally independent problems.

I would need to look at the code to find out whether that d_printf() is 
being used to display the actual results.

> Bug 767 refers to a limitation in Windows 95/98/ME.

...and smbclient.  The limitation is in the RAP call, really.

> Because those systems do not
> implement the NetrShareEnum RPC they can only report shares supported by the
> NetShareEnum RAP call. The RAP call can only report shares with 12 ASCII
> characters or less. Unicode or longer are not returned at all. Bug 767 is
> basically a "complaint" that smbclient doesn't implement the NetrShareEnum
> RPC. It only does the NetShareEnum RAP.

Yep.

I see Jerry's point that the NET command already does the RPC call, but I
favor the argument that says that smbclient is a general-purpose tool and
should be able to retrieve all of the share names.

I wonder, though, if it would work to change the reply format string from
B13BWz to B64BWz.

(No, actually, I don't.  Most implementations deal with these strings as 
simple constants.  Windows might actually processes them.  It would be fun 
to test but I wouldn't rely on it for real code.)

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org