outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Sun, Dec 12, 2004 at 01:07:52AM +0100, Jelmer Vernooij wrote:

> |>In Samba4 you would do this:
> |>
> |>	server services = rpc
> |>
> |>and this would make Samba only start the rpc server (so it would not
> |>start the builtin smb or ldap servers). It will only be listening on
> |>tcp ports 135 and 1024, plus any local rpc transports that are defined
> |>(such as /var/ncalrpc/DEFAULT and /var/ncalrpc/EPMAPPER) and any fixed
> |>ncacn_ip_tcp ports defined in the builtin IDL files.
> |

> |  [... me making stupid comments that make me feel sad...]
 
> I think what Tridge means is actually 'forwarding' the RPC data (for
> which Samba4 already has support, e.g. you can redirect a complete pipe
> to a remote server) instead of having a hack that bypasses the local
> endpoint and talks to a local pipe.

 is it possible to convey the security context that has been established
 up until that point?

 as explained yesterday, in TNG's ncalrpc implementation,
 the security context is conveyed by sending a few compulsory
 bytes that are a lookup into a table of security contexts (a tdb
 containing vuser_structs).


> |  i assume the samba 4 ncalrpc implementation is root-only-accessible, yes?
> Yes, at the moment.
> 
> |  or, did you find a solution to opening /var/ncalrpc/ local transports
> |  as ordinary users?
> We haven't looked at that yet though we will need to in the future -
> I've been working on some GUI utilities that need to talk to the local
> smbd somehow - ncalrpc would fit in perfectly here.

 you will need a _similar_ interface - one that can be accessed
 globally, where the default context is "anonymous" until proven
 otherwise.

 the purpose of the root-only-accessible ncalrpc transport is to provide
 communication optimisations *inside services running as root*.

 in other words, you don't want the headache of communicating
 between services over globally-accessible interfaces and
 having to prove authenticity once more, whether those interfaces be
 ncadg_ip_udp, ncacn_ip_tcp or ncacn_np or Other.

 and you _also_ need to add a "ncacn_ux" to the list of available
 transports just like there are ncacn_np etc listed above.



 it is vital that you do not confuse the roles of the two interfaces:
 they are mutually incompatible for the uses to which they are put.

 l.