msrpc daemon / pid.vuid

[Nicolas Williams]

On Sat, Feb 05, 2000 at 05:55:59AM +1100, Luke Kenneth Casson Leighton wrote:
> 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.

So? Encapsulate them.

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

No. I mean encapsulate *every* DCE/RPC packet forwarded to an MSRPC
daemon by smbd with PID/VUID information. I.e., send the PID, send the
VUID, send the DCE/RPC packet.

And to forget the TDB where you store information related to each share
connection, keyed by PID/VUID.

> _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.

Look, the communication between SMBD and MSRPC daemons is via IPC and
need not match exaclty what goes on the wire between clients and
servers. SMBD simply passes the DCE/RPC traffic transported by SMBD over
CIFS named pipes; what's wrong with encapsulating that DCE/RPC
internally with information needed by the MSRPC daemons?!

Nothing!

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

Encapsulate it. It does not change the semantics of DCE/RPC. Not one
bit.

> 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.

See above!

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

See above!

> 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.

Well, you could make each MSRPC program into a dynamic library that is
only linked in by smbd if needed (man dlopen()).

Or see above!

> > 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.

Well, there is an issue now: that by not encapsulating the DCE/RPC data
forwarded by SMBD to the MSRPC daemons you end up having to do strange
wasteful things like fork a gazillion extra processes.

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.