outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Thu, Dec 09, 2004 at 04:55:38PM -0600, Anthony Liguori wrote:
> Jeremy Allison wrote:
> 
> >So you're testing sending an rpc call, then doing a 1 byte at a time 
> >read back from the client, yes ? I don't think the server code handles
> >that currently. Can you send me your client test code so I can test
> >against Windows as well as smbd ?
> > 
> >
> No, I was doing a much simplier test.  I set up a pipe that intercepted 
> the SAMR pipe and tried to return a partial read in the pipe code.  Now 
> that I've thought about this, I don't think this is valid.
> 
> I think the pipe code behaves correctly.  The interface is just a little 
> confusing.  Perhaps lkcl could comment since he's the one that wrote it...
 
 well... i can only provide you with information based on the context
 of using a named pipe in samba TNG.

 if you were to choose to write an alternative inter-process
 communication system which would be much more suited to samba
 4 and samba 3 architecture (e.g. shared memory?), i cannot
 help you.

 however i sincerely hope that the code written for and used in samba
 tng for the past five years will be a suitable example.


 the way that samba tng's code works (lib/msrpc-client.c:receive_msrpc)
 is to first to make a timing-out read of 16-bytes (the size of a
 dce/rpc header), then to decode that, and then to read the data block
 indicated in the header - this time without a timeout.

 the reason for doing the timeout (about 30 seconds IIRC)
 is just in case something _does_ go wrong :)

 the reason for saying "i want 16 bytes" is because you aren't
 expecting, especially on a root-only-accessible unix-domain-socket,
 anything _other_ than 16-bytes

 and the reason for doing a blocking read of the remaining data is
 likewise: having read a header, we really _do_ expect to receive
 exactly the amount of data expected.


 now, the thing is that if someone _does_ send 1-byte-at-a-time to a
 samba-tng-smbd-server, then that data will be stuffed,
 one-byte-at-a-time down the corresponding unix-domain-socket.

 ... and because of the way that receive_msrpc() is written, it
 genuinely doesn't care (unless the bytes are sent spaced out at
 intervals of over two seconds!)

 and that's because of the use of read_socket_with_timeout().

 
 ... but this example is completely irrelevant for the purposes of
 samba 4 and samba 3.

 what i originally asked the samba team to consider was to make AN
 OPTION to out-source the four MSRPC functions (open, read, write, close)
 to a loadable module, the name of which can be specified in the
 smb.conf file.

 who and whether and how it is used is not really too relevant other
 than that it is strategically very important because it opens up so
 many possibilities that are at present totally closed.

 l.