Skip Menu |
 

From: epeisach@mit.edu
Subject: SVN Commit
In krb5_kt_add_entry: The MEMORY keytab does not make a copy of the
keytab_entry keyblock contents - but instead retains a pointer to the
incomming one.

In krb5_kt_get_entry and krb5_kt_get_next - a pointer to internal
keyblock contents memory is returned to the caller - which is subsequently
freed when tht caller invokes krb5_free_keytab_entry_contents.

Solution is to use krb5_copy_keyblock_contents() instead of simply copying
the structure.




Commit By: epeisach



Revision: 19140
Changed Files:
U trunk/src/lib/krb5/keytab/kt_memory.c
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
Date: Mon, 05 Feb 2007 14:06:03 -0500
RT-Send-Cc:
It would be desirable to actually use krb5_copy_keyblock if possible
or if not, at least initialize the keyblock using krb5_keyblock_init.
Date: Mon, 5 Feb 2007 13:14:25 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
RT-Send-Cc:
On Mon, Feb 05, 2007 at 02:06:19PM -0500, Sam Hartman via RT wrote:
Show quoted text
> It would be desirable to actually use krb5_copy_keyblock if possible
> or if not, at least initialize the keyblock using krb5_keyblock_init.

This is very important. When we integrated support for the Solaris
crypto framework in the Solaris krb5 code we needed to make sure that
krb5_keyblock is always properly initialized. I think you'll find the
same need eventually.

Nico
--
Date: Mon, 05 Feb 2007 15:05:45 -0500
From: Ezra Peisach <epeisach@MIT.EDU>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
RT-Send-Cc:
Sam Hartman via RT wrote:
Show quoted text
> It would be desirable to actually use krb5_copy_keyblock if possible
> or if not, at least initialize the keyblock using krb5_keyblock_init.
>
>
Umm.... The code is currently (now) using krb5_copy_keyblock_contents...
Is this sufficient?

Also - is there a reason krb5_copy_keyblock does not use
krb5_keyblock_init? And from
a parallel sense - shouldn't there be an equivalent for
krb5_keyblock_contents_init (in which the
keyblock itself is not inited?)

krb5_keyblock_init goes to the crypto library to malloc the keyblock and
for freeing it
as well... I would imagine that the copy keyblock routines would want
to use the crypto
library malloc arena as well...


Ezra
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
Date: Mon, 05 Feb 2007 15:28:58 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Ezra" == Ezra Peisach via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Ezra> Sam Hartman via RT wrote:
Show quoted text
>> It would be desirable to actually use krb5_copy_keyblock if
>> possible or if not, at least initialize the keyblock using
>> krb5_keyblock_init.
>>
>>
Show quoted text
Ezra> Umm.... The code is currently (now) using
Ezra> krb5_copy_keyblock_contents... Is this sufficient?

Not with the current code.

copy_keyblock_contents can (and should) call keyblock_init.

No, we do not want there to be an keyblock_init_contents routine;.
Date: Mon, 05 Feb 2007 15:41:14 -0500
From: Ezra Peisach <epeisach@MIT.EDU>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
RT-Send-Cc:
Sam Hartman via RT wrote:
Show quoted text
>>>>>> "Ezra" == Ezra Peisach via RT <rt-comment@krbdev.mit.edu> writes:
>>>>>>
>
> Ezra> Sam Hartman via RT wrote:
> >> It would be desirable to actually use krb5_copy_keyblock if
> >> possible or if not, at least initialize the keyblock using
> >> krb5_keyblock_init.
> >>
> >>
> Ezra> Umm.... The code is currently (now) using
> Ezra> krb5_copy_keyblock_contents... Is this sufficient?
>
> Not with the current code.
>
> copy_keyblock_contents can (and should) call keyblock_init.
>
> No, we do not want there to be an keyblock_init_contents routine;.
>
>
>
I will change the code to use krb5_copy_keyblock. I will leave it to
someone else
to modify krb_copy_keyblock to use krb5_keyblock_init...

Ezra
Date: Mon, 05 Feb 2007 16:28:34 -0500
From: Ezra Peisach <epeisach@MIT.EDU>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
Sam Hartman via RT wrote:
Show quoted text
>>>>>> "Ezra" == Ezra Peisach via RT <rt-comment@krbdev.mit.edu> writes:
>>>>>>
>
> Ezra> Sam Hartman via RT wrote:
> >> It would be desirable to actually use krb5_copy_keyblock if
> >> possible or if not, at least initialize the keyblock using
> >> krb5_keyblock_init.
> >>
> >>
> Ezra> Umm.... The code is currently (now) using
> Ezra> krb5_copy_keyblock_contents... Is this sufficient?
>
> Not with the current code.
>
> copy_keyblock_contents can (and should) call keyblock_init.
>
> No, we do not want there to be an keyblock_init_contents routine;.
>
>
>
Err - I would like some advise... Currently, nowhere in the keytab code
in the krb5_keytab_entry is the keyblock inited w/ the copy_keyblock or
keyblock_init code - as both
will try to malloc a krb5_keyblock structure. The krb5_keyblock_entry
contains a krb5_keyblock structure - not a pointer to one.

So - one solution is ugly... use keyblock_init, copy everything out of
there - zero the contents
pointer in the original - and free the keyblock.... This is ugly and
would do what you want.

Is there a better solution?


Ezra
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
Date: Mon, 05 Feb 2007 17:00:33 -0500
RT-Send-Cc:
No, just ignore keyblock_init. The interface is flawed.
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
Date: Mon, 05 Feb 2007 17:00:51 -0500
RT-Send-Cc:
(the keytab interface.
It should not have had a keyblock structure directly)
Date: Mon, 05 Feb 2007 17:10:45 -0500
From: Ezra Peisach <epeisach@MIT.EDU>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5429] SVN Commit
RT-Send-Cc:
Sam Hartman via RT wrote:
Show quoted text
> (the keytab interface.
> It should not have had a keyblock structure directly)
>
>
Yes - but unfortunately - it does.... I don't see a way around it...
The krb5_keytab_entry
has it and we are stuck with it... Heimdal has the same structure...

So given that I should not use krb5_copy_keyblock_contents - the only
other solution is to
do what is in the other keytab handlers - malloc my own keytab contents
memory... - which
is what I thought you were trying to avoid...

So - any solutions?

Ezra