Bug 430983 - gssapi bogotifies kerberos (and other?) error messages on 64-bit arches
gssapi bogotifies kerberos (and other?) error messages on 64-bit arches
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
8
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-30 17:16 EST by Tom Lane
Modified: 2013-07-02 23:17 EDT (History)
4 users (show)

See Also:
Fixed In Version: 1.40.4-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-15 21:12:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2008-01-30 17:16:15 EST
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):
krb5-libs-1.6.2-9.fc8.x86_64

How reproducible:
100%

Steps to Reproduce:
kdestroy, then try to connect to a kerberos service.  Correct behavior is:

(gdb) bt
#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 ]
(gdb) fin
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
161                     printfPQExpBuffer(errorMessage,
Value returned is $1 = 0x387727cc13 "No credentials cache found"

But try to pass the same error through gssapi:

(gdb) bt
#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, 
status_string=0x7ffffe08c2f0)
    at disp_com_err_status.c:58
#2  0x000000387760d307 in gss_display_status (minor_status=0x7ffffe08c30c, status_value=2529639107, status_type=2, 
req_mech_type=0x0, message_context=0x7ffffe08c308, 
    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:
(gdb) fin
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"

Actual results:
Unhelpful numeric dump of error code

Expected results:
The intended string for the message

Additional info:
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.
Comment 1 Nalin Dahyabhai 2008-01-30 17:53:17 EST
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.
Comment 2 Eric Sandeen 2008-01-30 18:05:22 EST
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.... :)

Thanks,

-Eric
Comment 3 Tom Lane 2008-01-30 19:03:37 EST
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.
Comment 4 Eric Sandeen 2008-01-30 19:06:20 EST
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 :)

Thanks,

-Eric
Comment 5 Fedora Update System 2008-01-31 16:12:56 EST
e2fsprogs-1.40.4-1.fc8 has been submitted as an update for Fedora 8
Comment 6 Fedora Update System 2008-02-02 03:59:12 EST
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
Comment 7 Fedora Update System 2008-02-15 21:12:11 EST
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.

Note You need to log in before you can comment on or make changes to this bug.