dce/rpc "client" api

[Luke Kenneth Casson Leighton]

On Wed, 23 Aug 2000, Andrew Tridgell wrote:

> > how about... samrd.  grepping for extern, this uses global_sam_name,
> > global_myname, global_sam_sid, global_builtin_sid.
> > 
> > wow, big deal.
> 
> There are a lot more variables that are affected than those you find
> by grepping for extern. In many cases we hide variables behind little
> set_foo() and get_foo() functions, with the variable itself declared
> static in the module.
> 
> There are also all of the global and static variables used inside all
> the Samba utility functions. Any of those may carry with them a
> semantic dependency on the current architecture where we have a single
> process per client.
> 
> You have already had to kludge your way around several of these in the
> TNG code. For example you return the name of the DCE/RPC pipe for %m
> in smb.conf macros when inside the msrpc daemon in the TNG branch,
> whereas in all released versions of Samba %m has been the clients
> netbios name. You do this because the netbios name of the client is
> not available inside daemons like msrpcd. If someone is doing printer
> accounting based on the netbios name of the client machine then this
> will break with the TNG code, but only from NT workstations (from
> Win9X it will keep working).

> I can understand why you put in this quick hack, as it allowed you to
> quickly get working code. Does it matter in this case? Not
> particularly much - we could decide to deprecate the %m macro (and %I
> etc) and document that it no longer is reliable. Alternatively we
> could include the client netbios name and other variables in the setup
> calls that smbd makes to the msrpcd daemon.

you know, i've been thinking about this.

what exactly is the code-path on an SMB connection to a dce/rpc pipe.

- TCP connection

- NBT session

- SMBnegprot

- SMBsesssetupX

- SMBtconX

- SMBopenX / NTCreateX

at which points do "global" variables get affected?

- TCP connection: client_name and client_addr through getsockname() and
getsockaddr().

- NBT session: NetBIOS name (remote_machine, local_machine)  this is
skipped for port 445, and is "faked" up by using getsockaddr().

- SMBnegprot: Protocol, max_recv, remote_arch.  [these are hardly relevant
to dce/rpc].

- SMBsesssetupX: global_client_caps, sesssetup_user, probably a few
others.  by the way, i will point out again that the global variable
sesssetup_user _is_ a bug / problem that should be removed / dealt with /
replaced.

- SMBtconX: nothing obvious, except maybe make_connection() is doing
something... ok, make_connection() looks like it's mostly doing, well...
connection-based stuff!


so, as i suspected from what i ran into difficulties with [and had to
hack-up], i think that the only relevant, significant global variables
that can _not_ be "reconstructed" from doing exactly the same (in a daemon
architecture environment) as what smbd does, namely to reload smb.conf,
are:

- client_addr()

- client_name()

- remote_machine (calling NetBIOS name)

- local_machine (called NetBIOS name)

the first two because you cannot get these from a unix domain socket.  the
last two because they come from the NetBIOS transport.

so, these i believe to be the _only_ four significant pieces of
information that must be transferred across the unix domain socket when a
pipe connection is initiated [i am avoiding the word "setup" because you
thought i meant at daemon-startup time, andrew, not select()-wait
accept()-then-fork() time].


[for the benefit of people that may not have been in the canberra office,
andrew and i discussed the parallels of having .so's and a domain
architecture.  other than the type of the globals changing possibly
causing problems, other than the types and number of arguments to
functions used by .so's causing problems when you use mix-match of smbd
from one revision and dce/rpc services from another, you have exactly the
same problem: if you add a global, remove one, from revision to revision,
you cannot mix-match].

lukes