[RFC] Making talloc_reference() safer.

[Jeremy Allison]

On Wed, Oct 26, 2011 at 08:38:20AM -0400, Stephen Gallagher wrote:
> On Wed, 2011-10-26 at 07:26 +1100, ronnie sahlberg wrote:
> > I personally think that the "hierarcy" vs "multi-parent" has to be
> > made at creation time and creation time only.
> > 
> > 
> > A bigger picture is that TALLOC is a hugely useful library which
> > should be encouraged to be used also externally in non-samba projects
> > as well.
> 
> For the record, talloc is used heavily in the System Security Services
> Daemon and Certmonger projects as well. Both of these are becoming vital
> pieces of the auth/authz puzzle on multiple Linux distributions.
> 
> To date, we've followed a strict policy of single-parentage (even going
> so far as to wrap some cases in our own refcounts).

This this a thousand time this !!!!

All C code eventually has to deal with refcounted pointers and ownership,
and it's a problem well enough understood that talloc doesn't *need* to
provide a new solution to this.

> The SSSD has a plugin-based architecture, and I certainly wouldn't want
> for a third-party authentication module to be able to add parentage to
> any of my variables without my knowing about it. I agree wholeheartedly
> that such decisions should be made at object instantiation and remain
> immutable.

Yes. This is the danger. talloc_reference allows refcounts to
persist across API boundaries between libraries and code developed
by different teams and projects. It's not a "safe" API in that
respect.

> > So API is really important. It is even more important that just "what
> > API change is needed to solve a problem in samba", it is "what API
> > makes sense to the average OSS developer working on his/her pet
> > project".
> 
> I'd love to see a world in which talloc_reference() is safe to use.
> However, as I said above, I want to be able to decide whether or not a
> particular variable is allowed to have multiple-parentage. The use of
> talloc_reference() should always be a conscious decision.

Having a different creation call for a referenced pointer and
having it be an immutable decision is the key to making this even
remotely usable.

Jeremy.