RFC trying to support non RPC Pipe service(s)

Noel Power nopower at suse.com
Wed Jul 30 03:36:38 MDT 2014


Hi Metze
So, I'm trying to get my head around this stuff again :/

On 08/07/14 10:03, Stefan (metze) Metzmacher wrote:
>
>>> The raw socket handling is already generic:
>>> - tstream_npa_accept_existing_send/recv() handles this for the server
>>>   see the code arround setup_named_pipe_socket() in
>>> source3/rpc_server/rpc_server.c
>>>   or tstream_setup_named_pipe() in source4/smbd/service_named_pipe.c
>>>
>>> - tstream_smbXcli_np_open_send/recv handles it for the client.
>>>   something like your patch to change the fragment size should be fine.
>>>
>>> So basically the client and server just have a tstream socket, which
>>> represents
>>> the named pipe. The server decides it is used in message or byte mode.
>>> So each side can read and write bytes to the socket.
>>>
>>> Then we helper functions to read a pdu from the socket
>>> and a helper function to write a pdu into the socket.
>>> They can use idl generated structures, but only it's easy to represent
>>> the protocol in something similar to ndr.
>>>
>>> The server can be a completely separated binary or forked from the main
>>> smbd.
>> I am still fond of the idea of getting as much stuff for free as I can,
>> if you don't see the value in having a more generic solution then would
>> there be objection to still using the (non idl generated) server side
>> hooks (e.g. raw_pipe_entry in source3/rpc_server/srv_pipe_register.c) I
>> could then manually register the server etc. instead of using the my idl
>> generated server hooks ?
> source3/rpc_server/*.c is going to die soon see
> https://wiki.samba.org/index.php/DCERPC
have to admit dont see the part about rpc_server/*.c going away,
unfortunately I don't fully even understand what the details involved in
that task are :-( Is there anything that gives a highlevel or more
descriptive view of what will replace source3/rpc_server/* ?

> The code from source3/rpc_server/srv_pipe_hnd.c can be simplified
> as we only have FAKE_FILE_TYPE_NAMED_PIPE_PROXY and don't really need
> this layer anymore.
I'd like to try and understand what you are suggesting above for the
server side
>  It can move to source3/smbd/pipes.c
Well moving that code to pipes.c is clear but not sure what you mean
with regard to the simplification of the code, do you just mean np_open
& friends can be simplified wrt handling testing/switching on
FAKE_FILE_TYPE ? because only FAKE_FILE_TYPE_NAMED_PIPE_PROXY is used,
or do you mean some deeper changes to the internals of those methods, if
so could you elaborate a little more what you mean
> And there we could have the very tiny infrastructure I described above.

>> I guess when I got to the point of thinking about how to provide the
>> server code (and following the rpc stuff for reference/learning) it
>> looked neater to hook into the existing loop there (and indeed there is
>> only a small amount of code on the server side is needed to do that)
>> That is in part because I didn't seperate it out either, it was
>> convienent to just make the decision in new method
>> 'handle_internal_pipe_socketpair' routine and I don't need to do any
>> hard coded switching on pipe names. 
[...]
> There we can share some of the code, but first we need to remove
> everything that's
> dcerpc specific. We just need an infrastructure to register a wellknown pipe
> names and a function (+ private_data) that starts the server loop for
> the internal service.
By server loop (in the dcerpc case) I assume you mean the call to
'dcerpc_read_ncacn_packet_send' right?
And the infrastructure you mention, and you expect that this is handles
all pipes eg. the normal dcerpc ones and weird ones like the 'raw' one I
am trying to handle? If so would I be correct in saying for all dcerpc
pipes a single 'function' will exist to call
dcerpc_read_ncacn_packet_send (and setup the associated callback) and
that for each other exotic pipe a custom 'function' can exist to provide
a similar server loop? If that is correct then np_open would still call
'make_internal_rpc_pipe_socketpair' (maybe renamed to
'make_internal_pipe_socketpair') passing FILE_TYPE_BYTE_MODE_PIPE or
FILE_TYPE_MESSAGE_MODE_PIPE as determined by the pipename from
registered info.  In this case 'make_internal_rpc_pipe_socketpair' would
no longer call the dcerpc related server loop, instead np_open would
call the assocated server_loop function (again determined by the
pipename from registered info) Am I off the mark here or did you mean
something entirely different?

thanks,

Noel


More information about the samba-technical mailing list