[PATCH] memset_s() and talloc_set_secure()
Jeremy Allison
jra at samba.org
Fri Oct 12 16:14:51 UTC 2018
On Fri, Oct 12, 2018 at 02:14:03PM +0200, Andreas Schneider wrote:
> On Thursday, 11 October 2018 21:06:20 CEST Jeremy Allison wrote:
> > On Fri, Oct 12, 2018 at 07:57:31AM +1300, Andrew Bartlett via samba-
> technical wrote:
> > > This still doesn't handle realloc correctly. The current code there
> > > only handles the non-pool case when ALWAYS_REALLOC is defined, which
> > > never is.
> > >
> > > You need to force all talloc_realloc() calls on secret memory though
> > > this path, as realloc() won't let you zero the memory after, and unlike
> > > the talloc header (which we overstamp and then restore) you don't do
> > > something similar with the content.
> > >
> > > talloc_realloc() is rare, and talloc_set_secret() is even more rare. I
> > > suggest just banning the combination and checking for things like
> > > talloc_realloc() and talloc_asprintf_append() in the small number of
> > > impacted code paths manually.
> >
> > +1 on this design decision. This is a very narrow talloc use
> > case and it would be better to restrict it to avoid internal
> > complexity.
> >
> > We've made this mistake before, let's not make it again.
> > All the talloc code around talloc_set_memlimit() is a
> > horrible increase in complexity for little (not at all
> > in Samba) used functionality.
>
> I've improved the code with metze today. talloc_realloc() is also working with
> talloc_keep_secret() now. I've also added a test for it.
>
> See attached patchset.
>
> Please review, we need more eyes on this.
Andreas, can you give me the use-case for this being in talloc ?
I can see the need for memset_s(), but why should this be inside
talloc rather than being called from specific talloc destructors ?
Jeremy.
More information about the samba-technical
mailing list