dce/rpc "client" api
Luke Kenneth Casson Leighton
lkcl at samba.org
Fri Aug 18 06:20:18 GMT 2000
On Fri, 18 Aug 2000, Gerald Carter wrote:
> Luke Kenneth Casson Leighton wrote:
> > andrew would like it to be an smb.conf option because
> > he would like a justification for the existence of
> > the ncalrpc loop-back transport, given that "ncacn_np
> > over SMB over 127.0.0.1 _should_ be sufficient".
> I was confused. You mean have an option to
> enable this support at all.
> I thought you meant
> an option to set the default transport layer used.
> > in TNG, the default transport for DCE/RPC _is_
> > ncalrpc. anything else [whether SMB or TCP]
> > *redirects* to ncalrpc.
> ok...we're moving off scope here a little I think.
> This should probably break off into another thread
> so as not to confuse everyone from the original
> > i intend to write a... a... [think-of-a-name,quick!]
> > dcetcpd "thing" which will be incredibly simple. it will
> > listen on a TCP port, it will send an "anonymous credentials
> > setup" over ncalrpc, and from then on it will
> > simply read_data() followed by write_data() and
> > vice-versa to communicate between the TCP socket
> > and the unix domain socket.
> ok...I know what you are trying to do here. However (and I've
> talked with you and others in the past about this), someone
> has to assemble the full PDU, right?
yes... well... sort-of.
the semantics [and i have just updated the comments] are that
cli_connect.c must receive / send full PDUs.
it is therefore the responsibility of the caller to ensure that data has a
full PDU in it, and the responsibility of the cli_nca*.c api-instances to
return a full PDU in rdata.
then, the callers of cli_connect.c do not need to _worry_ about PDU
reassembly. otherwise, you end up in a right mess.
e.g the current implementation of cli_ncacn_np.c [and all versions of
samba's client-side DCE/RPC code] uses an *incredibly* inefficient
- write request PDU
- read 16 bytes. decode this as a PDU header, including length of
- read remainder of response PDU (exactly length bytes).
this is baaaad.
_however_, if it were to be made more efficient (use SMBtrans) it would be
a simple matter of updating cli_ncacn_np.c and _no other code_.
> Currently in HEAD this
> is done prior to passing the PDU to the parsing layer of
> the code. I think that the dcetcpd daemon would need to
> assemable a full PDU before sending it to the rpc daemon.
> Someone has to check for attacks such as sending half a PDU
> and then no more. Do you follow me?
yes... however if you have an architecture where each client is allocated
its own process per socket, sending half a PDU only disrupts the client
itself, and noone and nothing else.
this principle is already employed in smbd, and i do likewise with the TNG
> I'm not a dce/rpc whiz I will admit.
you're fast becoming one :)
More information about the samba-technical