Bug 430983

Summary: gssapi bogotifies kerberos (and other?) error messages on 64-bit arches
Product: [Fedora] Fedora Reporter: Tom Lane <tgl>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: hhorak, kzak, nalin, oliver
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 1.40.4-1.fc8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-16 02:12:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Lane 2008-01-30 22:16:15 UTC
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 22:53:17 UTC
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 23:05:22 UTC
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-31 00:03:37 UTC
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-31 00:06:20 UTC
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 21:12:56 UTC
e2fsprogs-1.40.4-1.fc8 has been submitted as an update for Fedora 8

Comment 6 Fedora Update System 2008-02-02 08:59:12 UTC
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-16 02:12:11 UTC
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.