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