Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
Markus, Ken, Is this bug present in MIT krb5? Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
On Tue, Oct 16, 2007 at 12:33:43AM +0100, Markus Moeller wrote: > Maybe I miss something but I am not in control of the initialisation of the > keyblock. The problem is mcreds->keyblock ->contents in > krb5_copy_keyblock_data, which is not allocated in any function before and > not provided by the user. Yeah, I forgot. Solaris has a krb5_init_allocated_keyblock() function for this purpose. I suppose you could call krb5_init_keyblock() and do a struct copy, but that'd be asking for trouble (depending on what MIT wants to do in the future about caching derived keys (which Solaris does because we were able to modify krb5_keyblock before its layout and size became part of the ABI when we exposed the krb5 API). I'm either missing something else or you're right that there's a bug in krb5_get_credentials_core(). Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
Maybe I miss something but I am not in control of the initialisation of the
keyblock. The problem is mcreds->keyblock ->contents in
krb5_copy_keyblock_data, which is not allocated in any function before and
not provided by the user.
static krb5_error_code
krb5_get_credentials(krb5_context context, krb5_flags options,
krb5_ccache ccache, krb5_creds *in_creds,
krb5_creds **out_creds)
{
krb5_error_code retval;
krb5_creds mcreds;
krb5_creds *ncreds;
krb5_creds **tgts;
krb5_flags fields;
int not_ktype;
retval = krb5_get_credentials_core(context, options,
in_creds,
&mcreds, &fields);
.
.
.
static krb5_error_code
krb5_get_credentials_core(krb5_context context, krb5_flags options,
krb5_creds *in_creds, krb5_creds *mcreds,
krb5_flags *fields)
{
krb5_error_code ret = 0;
.
.
.
ret = krb5_copy_keyblock_data(context, &in_creds->keyblock,
&mcreds->keyblock);
Markus
- Original Message -
From: "Nicolas Williams" <[EMAIL PROTECTED]>
To: "Markus Moeller" <[EMAIL PROTECTED]>
Cc: "Ken Raeburn" <[EMAIL PROTECTED]>;
Sent: Tuesday, October 16, 2007 12:05 AM
Subject: Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
> On Mon, Oct 15, 2007 at 11:44:30PM +0100, Markus Moeller wrote:
>> You are right and some calling functions like krb5_copy_keyblock do
>> allocate, but not krb5_get_credentials(_core) if I now read the code
>> right.
>
> Whether it's a bug at all depends on what the krb5_get_credentials() API
> docs say about increds->keyblock. The lack of MIT krb5 API docs doesn't
> help.
>
> Now that you know what the calling convention for
> krb5_copy_keyblock_data() you should be able to fix your test program to
> properly initialize the keyblock field of the creds passed to
> krb5_get_credentials() as input creds.
>
> [I'll try to refrain from getting into the problems with encoding
> krb5_keyblock internals knowledge into your apps.]
>
> Nico
> --
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
On Mon, Oct 15, 2007 at 11:44:30PM +0100, Markus Moeller wrote: > You are right and some calling functions like krb5_copy_keyblock do > allocate, but not krb5_get_credentials(_core) if I now read the code right. Whether it's a bug at all depends on what the krb5_get_credentials() API docs say about increds->keyblock. The lack of MIT krb5 API docs doesn't help. Now that you know what the calling convention for krb5_copy_keyblock_data() you should be able to fix your test program to properly initialize the keyblock field of the creds passed to krb5_get_credentials() as input creds. [I'll try to refrain from getting into the problems with encoding krb5_keyblock internals knowledge into your apps.] Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
You are right and some calling functions like krb5_copy_keyblock do allocate, but not krb5_get_credentials(_core) if I now read the code right. Markus - Original Message - From: "Ken Raeburn" <[EMAIL PROTECTED]> To: "Markus Moeller" <[EMAIL PROTECTED]> Cc: Sent: Monday, October 15, 2007 11:23 PM Subject: Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris > On Oct 15, 2007, at 17:44, Markus Moeller wrote: >> If other people come across this issue(noticable when >> krb5_get_credentials >> is used in cross-realm situations) it had been identified in Opensolaris >> snv_57 (http://bugs.opensolaris.org/view_bug.do?bug_id=6565115) but >> still >> hasn't been fixed in source >> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ >> common/gssapi/mechs/krb5/krb5/krb/copy_key.c > > Your suggested fix is to have krb5_copy_keyblock_data allocate the new > storage, but the comment documenting the function says it assumes it's > already been allocated, and the body of krb5_copy_keyblock further down > does allocate the new storage before calling krb5_copy_keyblock. So if > I'm following this right, you'd be adding a memory leak to > krb5_copy_keyblock, wouldn't you? > > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
On Oct 15, 2007, at 17:44, Markus Moeller wrote: > If other people come across this issue(noticable when > krb5_get_credentials > is used in cross-realm situations) it had been identified in > Opensolaris > snv_57 (http://bugs.opensolaris.org/view_bug.do?bug_id=6565115) but > still > hasn't been fixed in source > http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ > common/gssapi/mechs/krb5/krb5/krb/copy_key.c Your suggested fix is to have krb5_copy_keyblock_data allocate the new storage, but the comment documenting the function says it assumes it's already been allocated, and the body of krb5_copy_keyblock further down does allocate the new storage before calling krb5_copy_keyblock. So if I'm following this right, you'd be adding a memory leak to krb5_copy_keyblock, wouldn't you? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Bug in krb5_keyblock_data function on Solaris 10/Opensolaris
If other people come across this issue(noticable when krb5_get_credentials is used in cross-realm situations) it had been identified in Opensolaris snv_57 (http://bugs.opensolaris.org/view_bug.do?bug_id=6565115) but still hasn't been fixed in source http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/mechs/krb5/krb5/krb/copy_key.c Markus Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
