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