outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

> The more I think about it, the more I come to the conclusion that the
> right approach for projects that wish to hook into our rpc server
> infrastructure is to build upon your existing rpc_server/remote/
> capability, along with the additional rpc transport support that
> Jelmer has added recently.
 
 what about projects that don't want to hook into the samba 4 rpc
 infrastructure, but purely need to leverage the IPC$ "named pipe"
 interface and also the SMB authentication context that gets carried
 along to the "named pipe"?

 what you are describing is a totally different ballgame, totally
 different problem, totally different set of solutions, that has
 nothing to do with the original proposal.

 the original proposal is solved in samba 3 - job done, dusted - with
 anthony's 68 line patch.

 THAT'S IT!  that's all that was ever needed!!!

 what you are describing is very very different - to help people and
 projects who may wish to utilise the samba 4 rpc infrastructure to
 simplify their projects.

 that's completely completely different.

 i cannot overemphasise this enough.



> I've CCd Luke Howard on this, as he is the only one who has real
> experience with building external rpc servers for Samba3. 

 andrew, andrew, andrew.

> I'd be interested in whether he thinks the above system would
> be workable for a potential future version of XAD combined
> with Samba4.

 the alternative solution that you propose is to strip out all
 signing, sealing and authentication information, yes?

 so that immediately makes samba the controlling party over all past,
 present and future signing, sealing and authentication mechanisms.

 that will be a lot of work for luke, and the developers of FreeDCE, to
 cater for.

 by contrast, the approach that i proposed is, as jeremy will no doubt
 tell you, "minimum necessary change" to achieve the desired goal
 [interoperability with other projects].


 the key to the approach that i proposed is as follows:
 
	 to outsource the security context and the name of the
	 ncacn_np transport as a "connection establishing" function
	 (in samba 3 that's namedpipe_create)

 you can then implement, SHOULD YOU SO WISH in samba 4, a version that
 does what you suggest: namely that you have a .dso that will strip out
 and manage and handle signing, sealing and authentication on behalf of
 those projects who do not wish to use it.

 and for a large number of projects who wish to use samba 4 as their
 infrastructure, that may well turn out to be extremely valuable.

 ... but for interoperability with existing DCE/RPC projects (samba tng,
 XAD and FreeDCE) it is an inappropriate solution.

 and as such, it is inappropriate for you to enforce that onto people.

 i would much appreciate it if people who understand and appreciate this
 could reinforce it and impress upon andrew, who has unfortunately
 disregarded my advice many times in the past, just how critical it is
 that this simple 68-line patch of anthony's be applied, and that samba
 4 adopt something that achieves the same results.

 

 for example: if you implement a version of this
 namedpipe_create+read+write+close dso for samba 3 that
 implements the samba 4 ncalrpc transport, you can start
 using samba 3 for its RPC services and samba 4 for SMB almost
 straight away.

 l.