outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

> 1) namedpipe_read and namedpipe_write's semantics aren't universally
> obeyed.  While testing, I found that Samba does not handle partial reads
> or partial writes.  

 as i described (or hinted at) in another message, the semantics of the
 namedpipe_read and namedpipe_write have to be that the write function
 passes on ALL data it is asked to (such that it can be received at the
 other end in one seamless block, too) and that the read function
 receives all data it is asked to (again, to minimise disruption).

 so any implementers of a libsmbnp_xx dso WILL have to conform to these
 semantics - namely that all data IS successfully passed over - even if
 it's one byte.
 
 ... or are you describing a completely different issue that has
 nothing to do with the issue at hand (namely, adding a dso mechanism)?
 i.e. a bug in samba that exists _without_ this outsourcing mechanism?


 oh.  by the way.

 yes.  now i remember.

 yes.  there was an issue that i successfully solved with
 TransactNamedPipe which does a read and a write.

 _now_ i remember.

 _that's_ why i added the timeout onto the implementation of the TNG
 unix-domain-socket read code.

 there's something you have to cater for in instances where you use
 TransactNamedPipe instead of SMBreadX and SMBwriteX.

 so, implementers of IPC mechanisms will need to watch out for that one,
 too.


> 2) If any of the functions are not function in the module it falls back
> to using Samba's pipe code.
 
 sensible.
 
 personally i would have followed andrew's advice which he gave me
 in approx-2000 which was to expect a single function which, when
 called, returns a table which contains pointers to the four functions.
 
 ... but hey, it really doesn't make any odds!

> 3) pipe_create gets passed a connection_struct and a vuid.  These fields
> are meaningless to an external library without a lot of Samba
> knowledge.  Thoughts?

 see quite-detailed-email-response to andrew's earlier message.

 briefly: tng and xad use the vuid and connection_struct to obtain the
 vuid_struct (containing the user information and schannel session
 information) and then shove that information over to the recipient
 [server].
 
 such that the recipient may seamlessly pretend that nothing has
 happened, no pipes or IPC mechanisms involved - nothing.

 the _only_ thing that's a bitch is that for complex smb.conf
 includings (include smb.conf.%M etc.) you LOSE a lot of that 
 context information across the pipe unless you go to a lot of painful
 steps to recreate it...

 ... only to find, as i did, that in the context of msrpc services, out
 of all possible sets of information that can be passed over via
 smb.conf complex-inclusions, most of the possibilities are bloody
 useless or mind-bendingly complex to deal with at an administrative
 level, and administrators are, IMO, much better off doing without them!!
 

 however - and i must stress this - my experiences with TNG
 are not directly relevant to samba 3 and samba 4: i mention
 them purely as examples: i am confident that any issues
 encountered will be solved in a manner suitable to samba 3
 and samba 4 design architecture.

 l.