dce/rpc "client" api
Luke Kenneth Casson Leighton
lkcl at samba.org
Wed Aug 23 07:48:51 GMT 2000
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.
More information about the samba-technical