Assigning 64-bit errcode_t to 32-bit krb5_error_code
tomas.kuthan at oracle.com
Fri Dec 5 05:42:46 EST 2014
(sorry for this being longish)
in krb5 sources error codes are mostly represented as two types:
typedef krb5_int32 krb5_error_code
typedef long errcode_t;
At some places values of the latter are assigned to variables of the
former. It would make sense, if values assigned to errcode_t were
guaranteed to fit in 32-bit integer (after all, errcode_t is 32-bit on
32-bit architecture). In that case, the discrepancy would be merely a
code purity issue.
But are there guaranties, that no function will ever return an error
code that would overflow 32-bit integer?
I identified two areas in the code, where errcode_t value is assigned to
1) Extended error hook functions
Most of the hook functions call krb5_get_error_message, internally
casting errcode_t to krb5_error_code and then back
extended_com_err_fn(..., errcode_t code, ...);
krb5_get_error_message(..., krb5_error_code code);
k5_get_error(..., errcode_t code);
(Provided errcode_t is supposed to be long) this would be easily fixable.
2) Profile API
Profile API uses errcode_t internally and public functions are declared
as returning long for error codes. At multiple places these longs get
assigned to krb5_error_code variables.
374 static krb5_error_code
375 os_init_paths(krb5_context ctx, krb5_boolean kdc)
377 krb5_error_code retval = 0;
387 retval = profile_init_flags((const_profile_filespec_t *) files,
And with profile plug-ins, the error code can origin in the plug-in,
depriving the code from the control of the specific values. Unless there
is some convention for the errcode_t values, the plug-in can return a
64-bit value, where the lowest 4 bytes collide with some defined
krb5_error_code value. In that case the 'lost of precision' in the
assignment results in a wrong interpretation of the error code.
Is there anything (besides common sense) forbidding errcode_t values
overflowing 32-bit integer?
More information about the krbdev