DCESRV stuff v3

[Stefan Metzmacher]

tridge at samba.org wrote:
 > Metze,
 >
 >  > I have a new patch :-)
 >
 > thanks!
 >
 > I like the approach in your patch, except for the remoteserver.pl
 > code.
 >
 > I don't think we need a code generator at all for the remote rpc
 > server backend (ie. we don't need any pidl changes at all). Instead I
 > think we can write a fairly simple single C file that uses the table
 > in librpc/gen_ndr/tables.c to do all of the remote rpc server. This
 > should be easier to maintain. The reason this is possible is that we
 > have the "struct_size" element in struct dcerpc_interface_call. That
 > element allows us to allocate the buffer to hold the rpc structure for
 > each call with the right size. See dcerpc_ndr_validate_in() for an
 > example of how this can be done.

I need a to look at this a bit closer ... but seems to work too:-)

 >
 >  > The problem which remains is that didn't now about the TCP ports of
 >  > TCP-0 endpoints in the epmapper (btw: the current implementation
 >  > fails here too! when you ask the smb pipe epmapper!!)
 >
 > hmm, I hadn't noticed that. The reason this happens is that
 > dcesrv_init() is called twice - once when the tcp listen sockets are
 > setup and again when a SMB connect is accepted. The second call is the
 > problem, we need some way to share the "struct dcesrv_context *"
 > between the SMB and RPC/TCP server contexts. A global would make this
 > simple, but doesn't feel right. I think the layering I've setup is the
 > real problem.

I don't know what you mean with layering.

I was thinking of something like this:
changing the server_context struct
to have subcontexts for an smb server and for a dcerpc server (maybe as a union).

We can then later extent this when we distinguish between raw smb sockets and
smb over Netbios.

so each socket gets a context for the protocol it is really listen on.

to better abstract the different protocol layers, we'll then have
subcontext for the nested protocol and so on.

What also would be usefull is to have a server_context struct for each listen socket
and then have a server_connection struct for each client connection instead of just dublicate
the server_context struct and use this also as a connection context.

This would make the things better understandable, for people which are not so familiar with the
hole code.

 >
 >  > I think to explicite register the endpoints in the to the epmapper,
 >  > so that it's also possible for an external application to register
 >  > a TCP endpoint which is directly handled by this application and
 >  > not by the smbd!
 >
 > yes, I'd like to be able to do that. The simplest is probably to do
 > this:
 >
 >
 > 1) implement RPC over unix domain sockets. Create a unix domain socket
 >    at startup that has only root rw privileges.
 >
 > 2) implement epm_Insert() in epmapper.c. Only allow it to be called
 >    when on the privileged unix domain socket
 >
 > 3) we'll need some way to communicate the insert to the top level
 >    dcesrv context. That means either our tdb messaging system to the
 >    top level process or instead store the epmapper info in a tdb.

sounds ok...

 > do you have time for a quick chat on IRC this afternoon? (thats
 > wednesday morning your time).

YES! I'm allready on irc:-)
But you just left:-(


-- 

metze

-------------------------------------------
Stefan (metze) Metzmacher <metze at metzemix.de>