dce/rpc "client" api

[Luke Kenneth Casson Leighton]

On Tue, 22 Aug 2000, Steve Langasek wrote:

> On Tue, 22 Aug 2000, Luke Kenneth Casson Leighton wrote:
> 
> > > If the shared library used that variable and you remove it then the
> > > shared library will no longer load. Bad luck.
> 
> > exactly.
> 
> > this in and of itself is a good reason for not promoting the .so system as
> > a viable substitute for the daemon architecture, which _does_ solve the
> > issue that you surmise that the .so system will solve, namely that it will
> > be possible to mix-and-match services from different development branches.
> 
> Luke, it seems to me that this is a non-issue.  *Any* time you change the
> interface between two pieces of code, you're going to break something, no
> matter if that interface is a Unix socket or a dlopen() call.

> But then, perhaps I don't understand as clearly as I should.  What global
> variables do you foresee a shared-lib implementation of DCE/RPC services
> needing to make use of?

actually, i was just discussing this with andrew.

on a service-by-service basis, the number of global variables [e.g
remote_machine, local_machine, client_name, client_addr, Protocol,
global_myname, global_myworkgroup, user_socket_options, ra_type just to
list a few which i can see in lib/util.c] *actually* used, by an
individual services, is very small.

in other words, a lot of those global variables are used by smbd and/or
nmbd, and are totally irrelevant to dce/rpc services.

let's take wkssvcd as an example.  this uses global_myname,
global_myworkgroup.  that is all.

how about... samrd.  grepping for extern, this uses global_sam_name,
global_myname, global_sam_sid, global_builtin_sid.

wow, big deal.

let's look at srvsvcd.  the only global is global_myname.  and actually,
that's a bug!!!  the response to netr_server_get_info() should return the
*caller's* server name :) :)



another question that andrew put to me was, what about "hosts allow" and
"hosts deny" options.  these are smbd-specific.  as smbd, through the IPC$
share is the "gateway" to the DCE/RPC over SMB services, smbd is, if you
are asking me, responsible for enacting the "hosts allow", "hosts deny"
parameters.  _not_ any of the msrpc services.


the other question is, what do you do about %macro substitution variables
[some of which are derived from global variables]. as i mentioned in other
messages, the whole issue of implementing, regardless of implementation,
dce/rpc services throws the whole %macro system into disarray.

the %macro substitution system was designed for use by "Samba, The File
And Print Server", and is designed to revolve around, essentially,
per-client, per-user and per-share configureability.

given that dce/rpc services are proxied over IPC$ [which is only _one_ of
the shares available], given that dce/rpc services inherit the
user-context of the IPC$ session BUT that they can over-ride that, the
whole %macro substitution system falls down pretty much straight away.

lukes