talloc issues

[tridge at samba.org]

Hi Michael,

 > This is what I meant above. What is my misconception here?

The misconception is that with the change in Metze's tree existing
working code can end up with a security hole. That fact that
talloc_free() doesn't fail isn't the problem - the problem is that it
reverses existing behaviour, and a lot of code has been written based
on that existing behaviour.

The change I've put in also changes existing behaviour, but the
consequence of the change is a possible memory leak, and in each case
that this leak happens we get a clear warning saying what needs
fixing.

So in one case we have something where the code will find the things
that need changing for us, and the consequence of the change is
relatively benign (a leak). In the other case we have no way to find
all the code that may be broken, and the consequence is a potential
security hole.

 > This is of course a brilliant technical realization.
 > But couldn't the same technique be applied to Sam's/Metze's
 > approach?

It isn't obvious to me that it can be. The mechanism relies on being
able to fail talloc_free when it is used in an ambiguous manner. I
don't see an easy way to reconcile that with the changes in Metze's
tree at the moment. There may be a way to do it, but I'd like to see a
patch that implements it rather than just assuming it will happen.

 > Tridge: Sorry for insisting. I am reviving this discussion
 > again and again now, because I want to understand, and I think
 > we need to come to a solution that is satisfactory
 > from the existing and future users point of view as well as
 > regarding the design of talloc. And therefore, I think we
 > need to find a solution on this higher level before loosing
 > ourselves in techincal details.

yes, I appreciate that, and if we were starting from a clean slate I'd
be much more interested in discussing what semantics we want.

I just don't want us to do a design based on a clean slate approach
and ignore the existing code.

Cheers, Tridge