talloc issues

[Sam Liddicott]

* tridge wrote, On 28/07/09 03:09:
> Hi Michael,
> 
>  > I am deliberately not going into technical details
>  > since I wanted to emphasize this superficial higher level
>  > point of view of the callers.
> 
> The technical details really do matter. As the example I gave shows,
> the proposals from Sam can create security holes in existing code that
> followed the API documentation as given. 

To be fair, talloc has had this risk of dangling refs all along, but it
is accurate to say that these talloc changes probably add many
additional security holes in existing code that has been behaved
intuitively correct up to this point.

I don't think this is under dispute but I wanted to make sure it was
clear to Obnox.

> Regardless of the high level
> aspirations of the proposed changes we can't just ignore
> this. Auditing the entire code base for such a change is an enormous
> task, and it isn't a task that anyone has volunteered to do. 
> 
> I also don't think a code inspection audit will be sufficient - we
> need a programmatic way of finding all existing use cases that are
> deprecated.

I think the audit will be lengthy whether we adopt any of the talloc
solutions mentioned so far; removing references, or changing the
meaning; however I address audit strategies in response to your other
message.

> That is why I added the location variable to the talloc reference
> structure, so that when code hit a situation that has changed we get a
> very clear message that allows for a quick fix. With the changes
> proposed by Sam and the patches in Metze's tree we would instead
> either get an abort() or we would get code dereferencing memory that
> has been freed. Both are not good outcomes.

This does make a very compelling case.

Sam