[jcifs] Re: SMB URL
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Thu Sep 13 08:45:10 EST 2001
hiya george,
good to hear from you.
the same argument may be applied to the telnet: URL
locator, and also to the http:// URL locator.
placing http:// or telnet:// in the argument below, that
users may be confused by having a port specified in URL locators,
disproves your hypothesis.
plus, remember, it's not users that have to deal with
a NetBIOS port-redirection response, but the application
writer (in a similar way that browser applications, not
browser users, have to deal with a REDIRECT response
from the HTTP server).
however, you are correct and also bring up another point:
the _default_ values are important, just as the default
values for http:// URLs are port 80 and default for telnet:
is ...urrr... 23? :)
so, the default for smb:// should be 139, and the default
for cifs:// should be 445.
in this way, my fiance, my dad, and your mum will not
have to know what port smb/cifs are running on, just
as they have no clue that HTTP runs on port 80.
luke
On Wed, Sep 12, 2001 at 05:24:24PM -0500, George Colley wrote:
> I think we are going over board here. I am not sure why the URL or any
> USER should care which port the connections is done on. I believe that
> is a problem for the implementation not the URL. Why should a user need
> to type one url to connect to a Winodws 2000 box and another to connect
> to a NT box. I think we would create a lot of confused users if this
> happen. Maybe if the only people that used it were cifs/smb experts that
> would be ok, but my mother just wants to type in a url and get connect.
> The code below the url is going to have to be smart enough to figure how
> it is connecting.
>
> George
>
> On Wednesday, September 12, 2001, at 04:50 PM, Luke Kenneth Casson
> Leighton wrote:
>
> > 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.
> >
> > hmmm.
> >
> >> 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
> > reasons.
> >
> > 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_
> > cifs/tcp?
> >
> > uh...
> >
> > 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.
> >
> > cool idea.
> >
> >> 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.
> >
> > thing.
> >
> > *thinks*
> >
> > 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.
> >
> > conflict :)
> >
> > 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
> > already...
> >
> >
> >> The draft it at
> >> http://search.ietf.org/internet-drafts/draft-crhertel-smb-url-01.txt
> >>
> >> So...
> >>
> >>> 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).
> >
> > well.....
> >
> > 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
> > in NT5.
> >
> > 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
> > tests?
> >
> >
> >> 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.
> >
> > difficult.
> >
> >>>> * 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
> >> resolution.
> >> 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.
> >
> >
> > oo goodie.
> >
> >> OFFSET - Synonym for START.
> >
> > synonyms discouraged.
> >
> >> 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
> >> side.
> >
> > 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.
> >
> > mmm :)
> >
> >
> > lukes
> >
> > ----------------------------------------------------------------
> > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > contains important info including how to unsubscribe. Save time, search
> > the archives at http://discuss.microsoft.com/archives/index.html
> >
> >
>
> Thursby Software Systems, Inc.
>
> George Colley Software Manager
> 5840 W. Interstate 20 Suite 160 Arlington, Texas 76017
> Phone: 817-478-5070 Fax: 817-561-2313
> email: colley at thursby.com web: www.thursby.com
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info including how to unsubscribe. Save time, search
> the archives at http://discuss.microsoft.com/archives/index.html
More information about the jcifs
mailing list