msrpc daemon / pid.vuid

Luke Kenneth Casson Leighton lkcl at samba.org
Fri Feb 4 20:43:07 GMT 2000


On Fri, 4 Feb 2000, Nicolas Williams wrote:

> On Sat, Feb 05, 2000 at 06:18:35AM +1100, Luke Kenneth Casson Leighton wrote:
> > > 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.
> > 
> > i went to a lot of trouble to remove the dependence between dce/rpc and
> > smbd.
> 
> The idea is not to insert PID/VUID information as extra NDR-encoded
> DCE/RPC arguments! The idea is to encapsulate, i.e., add a packet
> "frame" for the SMBD<->MSRPC protocol; these packet frames are terribly
> simple: they contain three fields: SMBD PID, VUID, DCE/RPC NDR data (I
> would include a length field, but you say that the MSRPC daemons should
> get that from the DCE/RPC data; I don't like that, but hey, what do I
> know: you're the DCE/RPC expert, not I).

:)

yep, that's what i used to have.

> > HEY!  *bing* OF COURSE!  dammit, dce/rpc already _is_ sutable to threaded
> > environments!
> 
> Luke, this is the second time we've done this, over the same exact idea.
> 
> :)

i did?? it _must_ be a good idea, then.

> 
> Probably what happened is that you forgot and this whole
> forking-one-msrpc-daemon-per-vuid hit you in the middle of the night
> when you must have been too tired to see that it was not an issue.
> 
> Ah. The dangers of coding late at night.

*sigh*.  yes, i trashed a boat-load of stuff i did last night, it was
just... too much in one go.

but i _did_ create a standard_sub_vuser, and i kept it, too.

> > YESS, nico, you're a genius.  COOL, it's even 16 bit!  see context_id,
> > below:
> 
> Genius? Nah. And I have no idea what the stuff below is.

each dce/rpc request contains this as part of the header.  it contains an
unused field, context_id, which is use to identify DCE/RPC "threads"...
_if_ you have a threaded environment.

well, with the smbd vuid, we _do_ have a threaded environment.

so i am going to overload context_id with the smbd vuid.  the only _other_
bit of info i need to get over there is the smbd process  id (PID).

and that's it!  we have the smbd PID.vuid index into the TDB database.


> > /* RPC_HDR_REQ - ms request rpc header */
> > typedef struct rpc_hdr_req_info
> > {
> >   uint32 alloc_hint;   /* allocation hint - data size (bytes) minus header and tail. */
> >   uint16 context_id;   /* 0 - presentation context identifier */
> >   uint16  opnum;        /* opnum */
> > 
> > } RPC_HDR_REQ;
> > 
> > /* RPC_HDR_RESP - ms response rpc header */
> > typedef struct rpc_hdr_resp_info
> > {
> >   uint32 alloc_hint;   /* allocation hint - data size (bytes) minus header and tail. */
> >   uint16 context_id;   /* 0 - presentation context identifier */
> >   uint8  cancel_count; /* 0 - cancel count */
> >   uint8  reserved;     /* 0 - reserved. */
> > 
> > } RPC_HDR_RESP;




More information about the samba-technical mailing list