libsmbclient: Browsing and a URI spec, updated.

[Avantel Systems]

I have been following your discussion for the last few days with great in=
terest
and support the direction you are going. While I recognize that it does n=
ot
impact _directly_ on the current task, I would like to raise a  point tha=
t
continues to hamper the use of samba for browsing support on (some) WAN /
VPNs. =20

The current behaviour of samba nmbd is (according to the policy decision
mentioned in the source code);=20

1) All group names (except names ending in 0x1C) are added as 255.255.255=
=2E255=20

2) All unique names ending in 0x1D are ignored with a positive response

One of the the results of this policy decision is that synchronized brows=
e
lists ( between samba servers accross a WAN ) contain only the broadcast =
address
for any workgroups for which the samba server is NOT the master browser. =
 Use of
that broadcast address by a browsing client looking for a list of servers=
 in
the workgroup, will return a positive result only if that workgroup is lo=
cal
(unless special measures are taken to ensure the broadcast reaches the re=
mote
LAN). =20

Proposed solutions to this problem include (among others) the possibility=
 that
samba be made capable of being the master browser for more than one workg=
roup. =20

To the extent that a solution to this browsing problem can be addressed b=
y
the development of the samba client library,  perhaps you could include t=
his
item in your design considerations.

Regards;

Alex Vandenham
Avantel Systems
Ottawa, Ontario, Canada

On Mon, 01 Jan 2001, you wrote:
> Hi,
>=20
>    Shall we be trotting home again,
>    but answer came there none.
>=20
> Caldera has commissioned the development of a Samba client library that
> will allow Linux and UNIX programs to be written to access resources on=
 SMB
> servers.  The clear goal is to allow the development of applications li=
ke
> the Windows explorer that allow users to browse resources on Linux/UNIX
> systems as well as SMB servers of all types.
>=20
> There has been much discussion about the issues of browsing and directo=
ry
> listing in the libsmbclient library, and things are starting to solidif=
y
> now.  This document sets out the resolution of the discussion, and
> represents what will be developed in libsmbclient.
>=20
> Firstly, however, some clarification on browsing under Windows.
>=20
> Browsing involves a complex series of activities and protocols (More
> details can be found in Special Edition, Using Samba and Ethereal disse=
cts
> many of the SMB calls used to implement browsing).=20
>=20
> On the server side, the NBNS and NBDS are used to register browsing rel=
ated
> names, distribute server and workgroup announcements, and manage the
> election of master browsers and backup browsers, etc.
>=20
> 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 th=
e
> browse server.
>=20
> Indeed, even when you want to see all the domains/workgroups on a netwo=
rk,
> a client connects to a backup browser and sends a NetServerEnum2 reques=
t on
> the IPC$ share with a server type of 0x00000000, which causes Samba, an=
d I
> assume NT servers, to list the workgroups/domains it knows about (their
> NetBIOS names only).
>=20
> A clear desire with libsmbclient is to be able support browsing as well=
 as
> access to resources on servers.  The question is, whether browsing of
> workgroups and servers can be unified with browsing of shares and
> directories on servers.  If this can be achieved, a single interface ca=
n be
> provided to users of the libsmbclient library.
>=20
> By noting that browsing the workgroups on a network is implemented in
> exactly the same way as browsing the servers in a workgroup, and that
> workgroup and server names are disjoint, we can unify the browsing of
> workgroups and servers on a network.
>=20
> A very clear approach is:
>=20
>    smb://
>       This is the top of the tree. It means list all workgroups.
>=20
>    smb://server|workgroup/
>       Since server names and workgroup names are mutually exclusive,=20
>       list all shares on the server or all servers in the workgroup.=20
>       If the name <workgroup><1D>has been registered, then list all
>       servers in the workgroup, otherwise, if <server><20> has been=20
>       registered, list all shares on the server.  There are some=20
>       obscure cases where it may be possible for the same name to be
>       registered as a server name (eg BADSERVER<20>) and as a local
>       master browser name (eg, BADSERVER<1D>), but this would only
>       occur in a badly configured network (more discussion here).
>=20
>       It should be noted here that workgroup also means ntdomain.
>=20
>    smb://server/share
>       List all directories in share on the server.
>=20
>    smb://server/share/directory
>       List all the objects in directory in share on the server.
>=20
> This has the advantage that it conforms to people'e expectations of how
> UNCs behave and how URLs behave, and we get to unify workgroup and serv=
er
> browsing with directory listings.
>=20
> As an aside, we should conform to RFC2396 and its URI syntax. This lead=
s to
> a very natural addition of authentication information, as RFC2396 provi=
des
> for 'userinfo', and provides a natural mechanism for specifying a usern=
ame
> and password, although it cautions against passing such information ove=
r
> the wire [see below for comments on security].
>=20
> A more complete form of the syntax, then might be:
>=20
>   smb://[[userinfo@]server[:port]][/share[/path[/file]]]
>=20
> where <userinfo> could be:
>=20
>   [user[:password]]
>=20
> A remaining question, though, is how can the domain (NT domain, that is=
) of
> authentication be indicated in the above <userinfo>. RFC2396 seems to o=
nly
> allow us a few remaining characters (';', ':', '&', '=3D', '+', '$', ',=
') or
> we must escape the character we use to mark the presence of a domain in
> which the authentication information is relevant.
>=20
> The consensus from the list is that the best syntax for <userinfo> is
>=20
>    [[domain;]user[:password]]
>=20
> While libsmbclient has a callback to allow authentication information t=
o be
> retrieved from the caller, any <userinfo> passed in via the URI may
> override that provided via the callback.
>=20
> The intention is that the smbc_opendir routine would be passed a URI
> formatted as above, and it would perform the appropriate operations to
> retrieve a browse-list or directory listing.  Subsequent calls to
> smbc_readdir would return the next object in the list.  Clearly, with e=
ach
> dirent returned, there will need to be an indication of the type of obj=
ect
> returned as well.
>=20
> A NOTE ON NETBIOS NAMES
>=20
> NetBIOS names are becoming increasingly obsolete. They are only require=
d 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.
>=20
> Thus, <server> should be allowed to be a DNS name, with CALLED names be=
ing
> set to *SMBSERVER, or the first component of the DNS name, or perhaps w=
ith
> each being tried in turn.
>=20
> However, browsing of workgroups and servers is all based around NetBIOS
> names, so until something like Active Directory is implemented, NetBIOS
> names will have to be used.
>=20
> COMMENTS ON SECURITY
>=20
> There would appear to be less of a security issue, in that these URIs w=
ill
> 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.=20
>=20
> However, the embedding of authentication information in URIs may lead t=
o
> harvesting of this information from memory and command lines, so care m=
ust
> be taken here.
>=20
> ACKNOWLEDGMENTS
>=20
> A number of people have made suggestions and criticisms that have been
> incorporated into this document.  I would like to thank Chris Hertel,
> Michael Sweet, Michael Allen, Steve Langasek, Simo Sorce and Kevin Colb=
y.
> Please accept my apologies if I have missed your contribution.
>=20
>=20
> 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