[19407] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: On krb5_db_alloc()

daemon@ATHENA.MIT.EDU (Will Fiveash)
Tue May 17 13:32:38 2016

Date: Tue, 17 May 2016 12:32:48 -0500
From: Will Fiveash <will.fiveash@oracle.com>
To: krbdev@mit.edu
Message-ID: <20160517173248.GA7032@oracle.com>
Mail-Followup-To: krbdev@mit.edu
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1463406465.18643.19.camel@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On Mon, May 16, 2016 at 09:47:45AM -0400, Simo Sorce wrote:
> On Thu, 2016-05-12 at 14:27 -0400, Greg Hudson wrote:
> > I would like to change the contract so that principal and policy entry
> > memory is all allocated with the allocator visible to the krb5
> > libraries, not the one visible to the KDB module.  I can see two ways to
> > accomplish this:
> > 
> > 1. Whenever we fetch a principal or policy entry, immediately copy it
> > into library-allocated memory and then ask the module to free its copy.
> 
> This is wasteful.
> 
> > 2. Document that KDB modules must allocate memory using krb5 library
> > functions or a compatible allocator.  Modules could call krb5_db_alloc()
> > to allocate an individual memory region, or a function like
> > krb5_copy_principal() for a more complicated field.  KDB modules can
> > also get away with just using malloc() as long as this stuff isn't used
> > on Windows.
> > 
> > In both of these proposals, krb5_db_alloc() and krb_db_free() would
> > change to just call realloc() or free() themselves.  The kdb_vftabl
> > entries for those functions would be removed.
> > 
> > Comments?
> 
> I'm for 2.

I agree with Simo.

-- 
Will Fiveash
Oracle Solaris Software Engineer
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post