s3-dcerpc: avoid talloc_move on schannel creds in cli_rpc_pipe_open_schannel_with_key().
Volker.Lendecke at SerNet.DE
Mon Aug 23 23:10:16 MDT 2010
On Mon, Aug 23, 2010 at 06:17:07PM -0700, Jeremy Allison wrote:
> > Is this really correct? I would have said that talloc_reference() is
> > the right thing to do here, as it is shared state. If one connection
> > does any call that updates the credentials chain, then the other
> > connections state must reflect that update, otherwise their calls
> > (SamLogon and other calls that do the credential chaining) will fail -
> > see how we have do this via a tdb on the server.
> > I know talloc_reference() isn't liked, but it really is the right thing
> > to do here.
> I'd rather do this with an explicit ref_count element in
> the structure, and attaching a destructor that decrements
> it - that way callers know there's something special going
> on here. Shared pointers like that should be the rare exception,
> not the rule and making it clear what is going on in these
> cases is better IMHO.
I've used talloc_reference in one place: tdb_wrap_open. Here
a completely hidden private structure is referenced, so that
the caller never has a chance to incorrectly talloc_free it.
To me this is the compromise: Completely hide the use of
talloc_reference behind a fool-proof wrapper that you just
can not use in a wrong way. I'm not sure this is doable in
this case here though, deep copies or an explicit reference
count might be better.
More information about the samba-technical