outsourcing DCE/RPC to alternate programs - runtime config option

[Stefan (metze) Metzmacher]

tridge at samba.org schrieb:

> Metze,
> 
>  > for samba 4 this could be easily done by implenting another
>  > ntvfs_ipc module that passes the data to a pipe and the epmapper
>  > module should be extented to return mappings which are registered
>  > by other applications via a private socket and a epm_Insert() call
>  > and we should then store the mapping in a persitent db
> 
> I don't think it is so useful to do this at the ntvfs level. The ntvfs
> level is before the bind, so you could only switch based on pipe name
> for ncacn_np, and you could not handle ncacn_ip_tcp or other
> transports at all. As a single ncacn_np pipe name is often used to
> handle many rpc interfaces (such as with lsass), this would not allow
> external implementations much flexibility in what interfaces they
> handle.
> 
> I think it would be much more appropriate to handle this using hooks
> in the rpc_server code. Something based on similar ideas to your
> dcesrv_remote.c code would perhaps be a good place to start. Maybe
> using an interface based on unix domain sockets for the forwarding of
> packets.
> 
> Of course, some external users might just want the raw pipe data, as
> not all named pipes are used for DCE/RPC, so a ntvfs level forwarding
> module isn't a bad thing to have, but I suspect the majority of
> external users will want to use it for DCE/RPC so something that suits
> that and allows support of all rpc transports is probably more widely
> useful.

other transports are not bound to smbd they can directly listen on the socket,
but you're right for the pipe vs. interface problem

-- 
metze

Stefan Metzmacher <metze at samba.org> www.samba.org