This is a discussion on Re: outsourcing DCE/RPC to alternate programs - - Samba ; On Sun, Dec 12, 2004 at 05:21:59PM +0100, Jelmer Vernooij wrote: jelmer, hi, i'm doing my usual thing of answering the questions you ask. it means that the message is getting somewhat long, and issues described several times. if you ...
On Sun, Dec 12, 2004 at 05:21:59PM +0100, Jelmer Vernooij wrote:
i'm doing my usual thing of answering the questions you ask.
it means that the message is getting somewhat long, and issues
described several times.
if you don't mind, after i've thought about it a bit more, i may
reply with a summary message as well - later.
> |>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?
> Not yet, currently the whole thing is root-accessible-only. We do
> actually do auth over it, as does Windows (see
okay... so if it's root-only-accessible, yet doesn't inherit
security context, what is the difference that makes it [samba 4
ncalrpc implementation] worthwhile having?
as opposed, say, to having just ncacn_unix_socket?
> | the purpose of the root-only-accessible ncalrpc transport is to provide
> | communication optimisations *inside services running as root*.
> Why? Windows uses them for regular users as well, otherwise there
> wouldn't be much point in authentication
> info passing...
> What would the purpose of such a root-only-accessible ncalrpc-like
> transport you propose be ?
exactly as you have it except that, like ncacn_np, it has
the ability to convey - or pre-inherit - security context
information - over from the calling program.
that key difference makes it a) worthwhile protecting as
root-only-accessible b) useful for optimisation purposes between
the reason _why_ you can add security context inheritance between
caller and called is _because_ it's root-only-accessible.
e.g. in the samba tng implementation of netlogond and samrd, netlogond
needs to contact the samr daemon to obtain account information, in
order to make the NTLM challenge-response calculations to feed
authorisation and session information out to a client.
if you were to use a samba 4 ncalrpc implementation, then
somehow you need to provide an authentication mechanism or
authenticate somehow over the ncalrpc connection between
the netlogond and samrd: or somehow provide an external
communication path that conveys security context between the
netlogon server and the samr daemon.
if you use the samba tng ncalrpc implementation, then you dig up the
(vuid and pid) index associated with the netlogond, initiate a
connection to the samrd using that (vuid+pid) to indicate to the samrd
that it should use the same [root] security context that netlogond is
presently running as, and netlogond will successfully convey its
present security context over to samrd with an absolute minimum of
have you considered this issue?
> | 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.
> Already did that.
> Samba 4 currently supports ncacn_ip_tcp, ncacn_np,
> and ncalrpc. For example, epmapper is available on:
> ncacn_np:[\\pipe\\epmapper]", "ncacn_ip_tcp:",
> "ncalrpc:[EPMAPPER]", "ncacn_unix_stream:[/tmp/epmapper]
that's really good.
> | 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.
> Which interfaces are you referring to here - ncacn_unix_stream and
> ncalrpc ?
okay, i assumed (or asked for confirmation and assumed to be
the case until otherwise told) that your implementation of
ncalrpc had the ability to, how-shall-we-say... "inherit",
like ncacn_np does, security context.
i understand now that you do not have the ability to inherit
[pass] security contexts.
therefore, the statements i made about it being possible to
use samba 4's ncalrpc transport for optimisation purposes
with respect to inter-service communication is wrong.
> What is their difference, other then that they are two different transports?
primarily, the key difference that is _worthwhile_ is of
inheriting security context.
ncacn_unix_socket cannot convey security context, just like
ncacn_ip_tcp and ncadg_ip_udp cannot.
there is no purpose, rhyme or reason for protecting an implementation
of ncalrpc as root-only-accessible if it doesn't have anything to
and if it doesn't inherit security context, then you might as well not
bother implementing it or using it, because it is effectively covered
by ncacn_unix_socket: all you have to do is specify
ncacn_unix_stream:[/var/ncalrpc/EPMAPPER] and, unless i am missing
something, you've pretty much got exactly the same thing...
...give-or-take a few details.
[i am led to believe that the samba 4 implementation of
ncalrpc has the ability to multiplex many endpoints over the
one socket? have i got that correct? ]
so to reiterate: what is it about the samba 4 ncalrpc implementation
that makes it worthwhile having, that ncacn_unix_socket does not, that
does not have the disadvantages of ncacn_np [i.e. having to go via a
full-blown SMB server] ?