concerns with ldap plugin and 1.5

[Will Fiveash]

On Thu, Jun 01, 2006 at 05:25:35AM -0600, Praveenkumar Sahukar wrote:
> >>> On Thu, Jun 1, 2006 at  6:23 AM, in message
> <20060601005356.GA27225 at sun.com>,
> Will Fiveash <William.Fiveash at sun.com> wrote: 
> > I have a number of concerns regarding the ldap plugin and schema in
> > the
> > upcoming MIT 1.5 release:
> > 
> > 
> > -  How is an existing db2 KDB migrated to a LDAP/Directory based
> KDB?
> 
> We are designing a migration tool for migrating the MIT db2 KDB to LDAP
> database.

Why can't one do a kdb5_util dump with the db2 KDB then reconfigure to
use the ldap plugin, initialize the directory for KDB use, then use
kdb5_util load to populate the ldap KDB?

Without this support, many customers are not going to be happy.

> > -  Is there no concern about interface consistency between use of
> >   kdb5_util and krb5_ldap_util?  The current situation where one
> must
> >   use kdb5_ldap_util to create/initialize a directory based KDB
> seems
> >   awkward to me.
> 
> We did consider to use kdb5_util interface for the LDAP backend. But
> the existing commands were not sufficient for the LDAP backend and a lot
> of additional LDAP backend specific options were needed even for the
> basic commands currently available in kdb5_util (like create). With
> these difference it was obvious for the kdb5_util interface to change.
> So we decided to go with a separate utility. 

Is kdb5_util not supposed to be used with the ldap plugin at all?
Above you say you are working on another utility to migrate between db2
and ldap.  Can you give a brief description of the relationship of the
various utilities to each plugin?

> > -  Nit: in kdb5_ldap_set_service_password() pwd.data should be
> memset(0)
> >   when it isn't in use.  Also, I see:
> > 
> >     /* set password in the file */
> >     pfile = fopen(file_name, "a+");
> > 
> >   Shouldn't the file being fopen()ed be tested to make sure the
> >   permissions and type are okay before modifying?  Doesn't seem safe
> to
> >   me.
> 
> This comment will be incorporated.

You should check your code and memset(0) all memory containing secret
keys before freeing.

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)