Netbios name %m not always correct
Christopher R. Hertel
crh at ubiqx.mn.org
Tue Oct 21 17:39:15 GMT 2003
On Tue, Oct 21, 2003 at 06:18:11PM +0100, David Lee wrote:
> [ Oops. I just realised that my original "I supplied two patches... that
> implements that spec" might have been ambiguous. Clarification: the code
> already existed, I merely provided two tiny patches to improve it.
> (There's a chance someone might have read it as "I supplied two patches
> ... that [completely, ex-nihilo] implements that spec.") ]
Doesn't matter. You've touched it, which is more than I've done. I'm the
theory guy. :)
> Do you mean "MS-RPC is inherently, and unavoidably, insecure"? Or that
> "the worms exploited patchable bugs in an otherwise (other bugs excepted!)
> secure mechanism"?
No, that's not really what I mean. There could be an argument made, since
the RPC calls are transported over all sorts of other protocols. I read
somewhere that W2K supports Active Directory Replication via SMTP. I have
to wonder whether they're doing RPC calls over that, too. Ouch.
I mention the recent RPC worms only because the result is that some folks
(probably correctly) will disable and/or block RPC access to their Windows
systems. The RPC-based Messenger Service is guarded particularly well
because there are tools available to send pop-ups across the wide
Internet. (I assume you block 135 at the border, though.)
Anyway, the current worm-infested climate will only serve to increase the
effort in "best effort", at least with regard to your goals.
> > One solution is to do *both* the NetBIOS and MS-RPC versions. Still, the
> > results are likely to be flakey.
> Thanks. I'm at the bottom of a steep learning curve here, but I was
> beginning to think that some sort of "both" might be the case, so it's
> good to have it confirmed by you.
> (Incidentally, our particular uses of the mechanism have always been with
> "reasonable efforts" rather than "guarantee".)
CIFS, in all its facets, does have a steep learning curve. I also work
for a University so I have some idea what you're looking at.
> So a revised smbclient+ might need to be configurable/driveable to send
> via one or more of a set of different types (SMBsend, MS-RPC, 3rd-P/[1..n]
> etc.). Looks like we're heading to a multi-choice plugin-type design here
> (analogous to passdb, VFS, etc.).
An updated smbclient might do SMBsend and MS-RPC. I don't see it doing a
third party thing since that would be outside of the scope of Samba. The
problem is that SMBsend does not return any success/failure. It just
sends. That means that there's no good way to know whether the message
was received. Of course, before performing SMBsend we could check for the
existence of the <03> NetBIOS name. That only gives us a clue (since we
don't know whether WinPopup or equivalent is running), but in a best
effort environment that should be enough. Not sure what MS-RPC does.
> Thanks again, Chris. Best wishes.
Keep in touch.
"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
More information about the samba-technical