Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Wed Sep 12 14:47:13 GMT 2001
On Wed, Sep 12, 2001 at 11:29:57AM -0500, Christopher R. Hertel wrote:
> Luke Kenneth Casson Leighton wrote:
> > hiya chris,
> Hi Luke,
> Good comments.
> Basically, the current draft covers only SMB over NBT. The move to
> include SMB over native TCP is based on...um...pressure from some
> vendors who have already started implementing.
> My original thought was
> to use smb:// for SMB over NBT and cifs:// for SMB over native TCP.
that is very sensible.
> I was, er, convinced that one URL form could handle both.
no it can't. was the following issue raised:
at some point, netbios is going to be deprecated
[maybe 15 more years?]
at that point, port 139 is going to be unused.
at _that_ point, or possibly even earlier, ms
may decide to 'do away' with the NetBIOS session
request, and simply skip straight to what is
now the exclusive domain of port 445, which
i will refer to as cifs/tcp. [and will also
refer to what is now the exclusive (except
for port redirection requests) domain of
port 139 as smb/nbt.]
at that point, it will become necessary to
distinguish between cifs/tcp and smb/nbt -
_on the same port number_, for legacy
also, what happens if you get a port redirection
response from an smb/nbt server on port 139 which
tells you to connect to port 445?
even if netbios is not deprecated, how do you
detect the difference between cifs/tcp:portnumber
and smb/nbt:portnumber at the moment?
oh, what, if it's port 139 then it's _definitely_
smb/nbt, and if it's port 445, then it's _definitely_
so i think that it is incredibly important to have
the distinction between the cifs/tcp style [netbios
sessionless] and smb/nbt style [full netbios] file
sharing, and for this to be reflected in the
url naming convention.
otherwise, you're going to have to add an extra
parameter that says, "hey, i _know_ this is on
port 139, but i _really_ want a cifs/tcp style
netbios sessionless here. pleeease?"
> That said, the original smb:// URL form was [is] designed to handle both
> SMB shares *and* browse list access. So:
> smb:// - would return the list of local workgroups.
> smb://workgroup/ - would return the servers in the workgroup.
urr... not obvious.
> smb://server/ - would return the shares offered by the server.
well, that's just like a directory listing, so if you treat the
shares as directories, then it's obvious.
my concern is that you'd have to distinguish the server-list in
the workgroup from a directory listing.
how about :
Content-type=text/servers for a server list and
Content-type=[usual directory format] for shares and directories
where text/servers is a new content type. there _may_
be a pre-existing content type, but heck :)
> Yes, that's overloaded. It's also convenient and there are mechanisms
> (outlined in the draft appendix) for determining whether smb://name/
> represents a workgroup or a server. The mechanisms are semantic, rather
> than syntactic, and do involve some network traffic.
don't think it's going to be enough.
for example, on an NT5 PDC, RestrictAnonymous defaults to 0x2.
this terminates any possibility of performing anonymous
browse list requests.
according to the appendix c, you must not treat a smb_name
as a workgroup if there is any auth info sent.
so the only reliable way to determine it and stil maintain
the [overload] semantics is to use a Node Status request
once you've done a Name Query. that's two round-trips
> The draft it at
> > On Tue, Sep 11, 2001 at 09:50:15AM -0500, Christopher R. Hertel wrote:
> > > * The URL will support both SMB over NBT and SMB over native TCP
> > > (port
> > > 445 semantics). I do *not* yet know if/how a browse list can be
> > > obtained from a W2K domain (a non-NBT browse list, probably
> > > stored in Active Directory), so I do not yet know if/how the SMB
> > > URL could be used to access a W2K Domain service list.
> > that is not part of file-serving, unless you want to
> > go down the route of specifying IPC$ as one of the shares,
> > whereupon it becomes a matter of specifying requests etc.
> Right. The URL form, as described and as currently specified in the
> draft, is overloaded and supports *two* service types. The most
> important is the SMB filesharing service, but the second (and equally
> important when you consider using this URL in browsers, KDE, etc.) is
> the browser service.
> ...and yes there are a lot of reasons that this is ugly but hey, the
> whole protocol is ugly. :)
> > i wouldn't recommend that this be done, not least because
> > dce/rpc is available over http (proxied by ms from port 80
> > to port 593, iirc correctly)
> Lost me. If DCE/RPC is available over http, then I assume that the AD
> browse list can be accessed using a browser.
well, there's a new pipe that's not been made public, that was
added to NT5, that apparently contains seven functions which
are explicitly for the purpose of obtaining browse information.
> That simply saves me the
> trouble of having to describe and outline a mechanism for retrieving
> that list and, further, for figuring out if smb://name/ represents 1)
> an NBT share, 2) a W2K share, 3) an NBT workgroup, or 4) a W2K Domain
> Active Directory server name (for obtaining the AD browse list).
it _does_, but this would assume that the dce/rpc redirection
is enabled, which it is only by default when you install
IIS 5.0 and, possibly, Exchange.
so it can't be counted on, and it certainly can't be counted
on on legacy systems.
and, also, implementing DCE/RPC is a lot of work, unless
people are prepared to use the OSF 1.1-licensed project,
FreeDCE (see dcerpc.net - shameless plug, shameless plug),
and also help investigate and document the new browser pipe
regarding 1) and 2), can you subdivide that by using smb:...
and cifs:... respectively? or, at the very least, assuming that
they are that respective way round first of all in the heuristics
> The overloading is quite out of hand as it is. Being able to say
> "Active Directory browse lists are not supported by the SMB URL, use
> HTTP instead" would be nice.
DCE/RPC over HTTP, you mean.
> > > * The trailing "query string" syntax, common in URL strings, will
> > > likely be supported for the purpose of adding additional
> > > parameters such as the WINS server IP address, the Called Name to
> > > be used, etc.
> > have you considered specifying parts of files?
> > (?start=NNNN&length=NNNN)
> The idea crossed my mind. I want to get a list of valid tags because I
> really do *not* want people to add new tags without consultation with
> other CIFS implementors. It would be best if an organization, such as
> SNIA, were to maintain the list of valid tags.
you'd best put that in the rfc.
'to register a tag, please contact http://xxxyyy'
same procedure as icann?
> So far I have:
> NBNS - DNS name or IP address of the NBNS to use for NetBIOS name
> NBDD - DNS name or IP address of the Datagram Distribution Server
> to use for datagram distribution (I know, no one implements
> the NBDD but it is included for completeness).
> WINS - Synonym for NBNS.
standards shouldn't really have synonyms.
specify one and only one way to do things.
> SCOPE - Scope should be included in the server identifier field, but
> I am adding room for it here as well.
good idea because NetBIOS names tend to contain fullstops... :)
> START - As you suggest.
> LENGTH - As you suggest.
> OFFSET - Synonym for START.
> CALLNAME - When specifying a server by DNS name or IP address, it is
> sometimes necessary to also specify the called name to be
> used. This tag allows the NetBIOS called name to be
> specified in the URL string.
cool. yuck, but cool.
> SERVER - When specifying a server by NetBIOS name, if that NetBIOS
> name cannot be resolved locally this field allows the server
> IP address or DNS name to be listed. (That is, it's the
> reverse of the CALLNAME tag.)
> > [also have you looked at DAV?]
> Not yet. I am aware of it. It may "win" in the long term but, as I
> mentioned, some vendors are already implementing the smb:// URL so we
> might as well have a spec for it. :)
> > also, does the specification explicitly mention streams, which
> > are referenced via two colons followed by the stream name
> > (e.g. filename::data is the data stream, synonymous with the
> > file itself).
> No, it doesn't. I am aware of them, however, and I feel that it is safe
> to leave them out of the URL spec as they are part of the filesystem
> syntax rather than the URL syntax.
you might still want to explicitly include it in some of
the examples, otherwise people may not realise that it's
possible, and that's where the mistakes creep in.
> > a lot of security mistakes have been made in IIS plugin
> > components due to parsing of URLs that 'forget' about
> > being able to reference the filename as sourcecode.asp::data
> > which of course doesn't have an extension of .asp so is
> > allowed.
> Right. That happens on the server side, however, and not on the client
oh, *duh*, of course.
.... what about proxy-redirectors?
> You can (I have) use string syntax in http URL strings in, for
> example, Netscape. I'm pretty sure Lynx allows it too.
> It is the server's responsibility to parse the path string. When we
> implement such things in Linux, etc., we may run across the same
> problems that the Windows and Mac systems have seen. Hopefully, we will
> have learned the lessons by then.
More information about the samba-technical