s3-dcerpc: avoid talloc_move on schannel creds in cli_rpc_pipe_open_schannel_with_key().

[Volker Lendecke]

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.

Volker