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 _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
> rfc.

hm.  true.
> > 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
domain architecture.

>  I'm not a dce/rpc whiz I will admit.

you're fast becoming one :)

More information about the samba-technical mailing list