libsmbclient: Browsing and a URI spec?

[Richard Sharpe]

Hi,

   And thick and fast, they came at last
   and more and more and more

Bonus points to those who can tell me where the quote comes from.

NOTE: This document is not the last word on this subject, but I will try to
update it in light of discussions.  It does, however, represent my
reasoning on the subject and reflects what I have gained from the
discussion that went on.

There has been much discussion about the issues of browsing and directory
listing in the libsmbclient library, and I wanted to progress this some
more, and to lay out what I see as the important parts.

Firstly, however, some clarification on browsing.

Browsing involves a complex series of activities and protocols. 

On the server side, the NBNS and NBDS are used to register browsing related
names, distribute server and workgroup announcements, and manage the
election of master browsers and backup browsers, etc.

On the client side, however, a broadcast request is sent to the local
master browser NetBIOS name via an IP broadcast to retrieve the backup
browser list, but  after that, Lan Manager requests, like NetServerEnum and
NetShareEnum requests are made after connecting to the IPC$ share on the
browse server.

Indeed, even when you want to see all the domains/workgroups on a network,
a client connects to a backup browser [I think] and sends a NetServerEnum
request on the IPC$ share with a server type of 0x00000000, which causes
Samba, and I assume NT servers, to list the workgroups/domains it knows
about (their NetBIOS names only).

Now, my main concern is whether browsing can or should be unified with
directory listing. A second question is: What should be the form of the URI
used to convey all the required information, both when accessing files but
also when browsing.

However, before doing that, let me say that there is little doubt that
browing a single workgroup should be unified with directory listing; it is
the presence of workgroups/domains that raise problems.

A very clear approach is:

   smb://              means list all servers in the current workgroup.

   smb://server/       means list all shares on server.

   smb://server/share  means list all directories in share on server.

and so on. 

This has the advantage that it conforms to people'e expectations of how
UNCs behave and how URLs behave. The disadvantage is that
workgroups/domains from a browsing perspective do not have a natural place
in this scheme, and they cannot be easily shoehorned in.

As an aside, we should conform to RFC2396 and its URI syntax. This leads to
a very natural addition of authentication information, as RFC2396 provides
for 'userinfo', and provides a natural mechanism for specifying a username
and password, although it cautions against passing such information over
the wire [see below for comments on security].

A more complete form of the syntax, then might be:

  smb://[userinfo@][server[:port]][/share[/path[/file]]]

where <userinfo> could be:

  [user[:password]]

A remaining question, though, is how can the domain (NT domain, that is) of
authentication be indicated in the above <userinfo>. RFC2396 seems to only
allow us a few remaining characters (';', ':', '&', '=', '+', '$', ',') or
we must escape the character we use to mark the presence of a domain in
which the authentication information is relevant.

Unless I have misinterpreted RFC2396, my suggestions would be:

  [user[;domain][:password]]

or

  [user[+domain][:password]]

But I am open to suggestions.

Finally, however, the issue of workgroups/domains intrudes. These would be
most naturally accomodated by supplanting the server down one level, eg:

  smb://[userinfo@][workgroup[/server[/share[/path[/file]]]]]

but this seems unnatural and the objection can be made that DNS-style
domains are not browsed in this way with a normal URI, other mechanisms
must be used to obtain the relevant list of domains.

Thus, my preference now is to exclude workgroups/domains from the URI
syntax, and to use the URI syntax listed above, but I am prepared to listen
to argument.

I would like to provide additional routines to list workgroups, but this
itself may require the provision of authentication information, as the
process of listing the workgroups requires a connection (NetBT) to the
backup browser, and a TCON to the IPC$ share.  This may require a
SessionSetup&X with a valid username and password pair.

An open question at this stage is whether or not this authentication
information should be provided using the callback facility already
provided, or whether or not they should be passed in via parameters.

A NOTE ON NETBIOS NAMES

NetBIOS names are becoming increasingly obsolete. They are only required by
older Microsoft OSes. Samba does not care about NetBIOS names (but does use
them for virtual servers), and NT 4.0 (I believe) and certaily Win2000
allows the use of *SMBSERVER as the called name.

Thus, <server> should be allowed to be a DNS name, with CALLED names being
set to *SMBSERVER, or the first component of the DNS name, or perhaps with
each being tried in turn.

COMMENTS ON SECURITY

There would appear to be less of a security issue, in that these URIs will
not be passed over the wire; they are for specification to the library,
which will pull them apart and use the appropriate pieces where needed. If
the server supports 'encrypted' passwords, then that will be used. 

However, the embedding of authentication information in URIs may lead to
harvesting of this information from memory and command lines, so care must
be taken here.

Regards
-------
Richard Sharpe, sharpe at ns.aus.com
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba