Red Hat Bugzilla – Bug 430983
gssapi bogotifies kerberos (and other?) error messages on 64-bit arches
Last modified: 2013-07-02 23:17:31 EDT
Description of problem:
gss_display_status() returns wrong/unhelpful error messages for error codes that are more than
31 bits wide, if on a 64-bit platform.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
kdestroy, then try to connect to a kerberos service. Correct behavior is:
#0 error_message (code=-1765328189) at error_message.c:48
#1 0x00002aaaaaab420a in pg_krb5_init (errorMessage=0x643148, info=0x7ffffe08c1f0) at fe-auth.c:161
[ rest of stack is not interesting ]
Run till exit from #0 error_message (code=-1765328189) at error_message.c:48
0x00002aaaaaab420a in pg_krb5_init (errorMessage=0x643148, info=0x7ffffe08c1f0) at fe-auth.c:161
Value returned is $1 = 0x387727cc13 "No credentials cache found"
But try to pass the same error through gssapi:
#0 error_message (code=2529639107) at error_message.c:48
#1 0x0000003877609edd in gssint_g_display_com_err_status (minor_status=0x7ffffe08c30c, status_value=2529639107,
#2 0x000000387760d307 in gss_display_status (minor_status=0x7ffffe08c30c, status_value=2529639107, status_type=2,
status_string=0x7ffffe08c2f0) at g_dsp_status.c:88
#3 0x00002aaaaaab43db in pg_GSS_error_int (mprefix=0x2aaaaaac5a00 "GSSAPI continuation error", msg=0x64b1fd "",
msglen=163, stat=2529639107, type=2) at fe-auth.c:358
[ rest of stack not interesting ]
and you get a useless result:
Run till exit from #0 error_message (code=2529639107) at error_message.c:48
0x0000003877609edd in gssint_g_display_com_err_status (minor_status=0x7ffffe08c30c, status_value=2529639107,
status_string=0x7ffffe08c2f0) at disp_com_err_status.c:58
58 if (! g_make_string_buffer(((status_value == 0)?no_error:
Value returned is $2 = 0x3877001cf0 "Unknown code krb5 195"
Unhelpful numeric dump of error code
The intended string for the message
The culprit is g_display_com_err_status(), wherein an OM_uint32 representation of the error code
is passed to error_message(), which expects a long. On a 64-bit architecture the uint32 will be
padded with zeroes, whereas error_message is expecting a sign-extended value.
A minimum fix would be to cast status_value to signed int32 before letting it be widened to long.
However, I wonder whether there aren't some more fundamental issues here. Presumably the intent
is that no error code will ever be too wide for 32 bits (else the code cannot work on 32-bit arches)
so maybe the code in error_messsage.c should be modified to deliberately mask off high order bits
to prevent confusion of this type in other places.
BTW, it seems like a pretty bad idea that there are two different versions of error_message.c in use
in the same set of libraries. I am not quite sure who is responsible for pulling in libcom_err from
e2fsprogs, but that contains a version of error_message.c that is subtly different from the one in
the krb5 sources, and it scares the heck out of me that different parts of the program seem to be
calling different ones of the similarly-named routines. That doesn't seem to be directly related
to the misbehavior I'm seeing, but maybe it is a factor in other bugs? In any case it's confusing.
The libcom_err implementation in e2fsprogs aims to provide the interfaces which
libkrb5 needs, in part that I can avoid bundling a separate one with a different
soname, but I'm pretty sure that this is specific to the e2fsprogs version (the
krb5 bundled libcom_err casts the value to unsigned and masks off high bits, so
it should avoid this problem).
This particular bug should be fixed in e2fsprogs 1.40.4 or later (upstream bug
#1809658), which masks off the bits as you suggest. Bouncing this report to
that component so that Eric sees it.
e2fsprogs-1.40.4 is in rawhide; any chance you could give it a whirl and confirm
that it fixes things for you? (You may need to get the srpm and rebuild, if
that's not too much trouble...)
I hadn't gotten fired up to push 1.40.4 to F7/F8, but now if I have a reason.... :)
Actually what I find in rawhide is 1.40.5, but installing that indeed fixes it. So if you could push to F8 it'd
be much appreciated here.
Thanks for testing - I'll aim to push 1.40.4 to f8/f7 testing repo tomorrow -
1.40.5 is a wee bit more invasive, larger default inodes & such, and it *just*
went to rawhide... I'll let that soak a bit more :)
e2fsprogs-1.40.4-1.fc8 has been submitted as an update for Fedora 8
e2fsprogs-1.40.4-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update e2fsprogs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1286
e2fsprogs-1.40.4-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.