libsmbclient: Browsing and a URI spec?

[Simo Sorce]

On Sun, 31 Dec 2000, Richard Sharpe wrote:

> 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.

I feel like prepending domain to the authentication part is better, partly
because it's how ms has done it (dom\usr) and partly because
hierarchically user belong to domain and not the countrary so domain
should come first.

  [[domain;]user[:password]

>
> 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 totally agree, but a way to specify which is the default workgroup
should be specified.

>
> 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.

I think an utility similar to nslookup will be perfect.

> 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.

Happy new year,
Simo.

-- 
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
-----------------------------------------------------------------
Be happy, use Linux!