Re: ANNOUNCE: nfs-utils-1.2.2 released.

Kevin Coffman
2010-03-09T15:19:00Z

2010/3/9 Lukas Hejtmanek <xhejtman@ics.muni.cz>:
> On Mon, Mar 08, 2010 at 02:48:25PM -0500, Jeff Layton wrote:
>> What would probably help some is to do a bit more analysis with gdb.
>> Maybe see if you can determine where it's falling down in libgssglue
>> and why. That may help us to determine what the actual problem is.
>
> using gdb and debug in libgssglue, it looks like there is a mess in
> structures:
> Core was generated by `/tmp/nfs-utils-1.2.2/utils/gssd/gssd -vvv'.
> Program terminated with signal 11, Segmentation fault.
> #0 =A00x00007f8a77c0a5ef in __gss_get_mechanism_cred (union_cred=3D0x=
1be3a00,
> mech_type=3D0x6114f0) at g_glue.c:295
> 295 =A0 =A0 =A0 =A0 =A0 =A0 if (g_OID_equal(mech_type, &union_cred->m=
echs_array[i]))
> (gdb) print *union_cred
> $1 =3D {count =3D 29243904, mechs_array =3D 0x1, cred_array =3D 0x1be=
8be0, auxinfo
> =3D {name =3D {length =3D 29264896, value =3D 0x11},
> =A0 =A0name_type =3D 0x1be8bc0, creation_time =3D 140232705185984, ti=
me_rec
> =3D 1268127776, cred_usage =3D 86400}}
>
> this seems to be because gss_acquire_cred is defined in both libgssgl=
ue.so and
> libgssapi_krb5.so
>
> and these two libs do not agree on gss_union_cred_t:
>
> libgssapi_krb5:
> typedef struct gss_cred_id_struct {
> =A0 =A0 =A0 =A0struct gss_cred_id_struct *loopback;
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 count;
> =A0 =A0 =A0 =A0gss_OID =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mechs_array;
> =A0 =A0 =A0 =A0gss_cred_id_t =A0 =A0 =A0 =A0 =A0 *cred_array;
> =A0 =A0 =A0 =A0gss_union_cred_auxinfo =A0auxinfo;
> } gss_union_cred_desc, *gss_union_cred_t;
>
> libgssglu:
> typedef struct gss_union_cred_t {
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 count;
> =A0 =A0 =A0 =A0gss_OID =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mechs_array;
> =A0 =A0 =A0 =A0gss_cred_id_t * =A0 =A0 =A0 =A0 cred_array;
> =A0 =A0 =A0 =A0gss_union_cred_auxinfo =A0auxinfo;
> } gss_union_cred_desc, *gss_union_cred_t;
>
>
> --
> Luk=E1=B9 Hejtm=E1nek

I've built nfs-utils with and without --disable-tirpc and don't see
this problem.

It could be a bug, but I would think that other [Debian and other]
testers would have already hit it.

I'm concerned that perhaps your build issues may have somehow
introduced a [bad] mix of headers? (i.e. were things built using the
libgssglue headers, or the Kerberos headers?)

K.C.