msrpc daemon / pid.vuid

[Luke Kenneth Casson Leighton]

On Fri, 4 Feb 2000, Nicolas Williams wrote:

> On Sat, Feb 05, 2000 at 05:35:52AM +1100, Luke Kenneth Casson Leighton wrote:
> > > Luke, can you make sure that smbd communicates with the MSRPC daemons in
> > > SAMBA_TNG in a way that allows the running of more than one set of
> > > daemons per host, with each set being conceptually separate as I showed
> > > above?
> > 
> > actually, i have to do that.  i am going to have to associate _one_ msrpc
> > daemon per _separate_ smb virtual user id (vuid).
> 
> Why? I don't get it. And I read your posts today and yesterday.
> 
> Why can't you pass the PID/vuid along with the DCE/RPC NDR packets to
> the msrpc daemons??

because dce/rpc pdr packets have nothing to do with PID.vuid, there's no
space for it.

you mean, in the _setup_ phase, pass over the PID.vuid?  yes, i will have
to do that.

_except_.... except, the current usage of the client-side MSRPC code only
has the server  name in it, as per DCE/RPC specifications.  remember "the
cached credentials conflict with existing credentials?"  this is to that a
DCE/RPC call with a server name (\\. or \\ip.add.re.ss or \\NETBIOSNAME)
can resolve ONE and ONLY one set of cached credentials.

there's no means in DCE/RPC to do this:

LsaOpenPolicy("lkcl@\\SERVERNAME, &policy_hnd).

and there's _definitely_ n omeans to do this:

lps_open_policy("PID.vuid@\\SERVERNAME, &policy_hnd);

so the contexst "used" to be just \\servername and _implicitly_ it used to
be smbd PID by forking() smbd.

now i have to either fork() on a vuid (no way!) OR... maintain INDEPENDENT
sets of msrpc connections on a per-vuid basis.

or, we go back to the proginal architecture in 2_0 / 3.0: call msrpc
functions _inside_ smbd, directly.  i don't want to do this, i like the
msrpcd independence.
 
> What I had in mind is that the directory containing the Unix sockets (or
> whatever it is you use for IPC) be configurable.
>
it's a single entry point.

> Of course, if each smbd forks its own msrpc daemons then there's no
> issue as far as HA goes.

yep.