Assigning 64-bit errcode_t to 32-bit krb5_error_code

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Assigning 64-bit errcode_t to 32-bit krb5_error_code

Tomas Kuthan
Hi,

(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
krb5_error_code variable.

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);
             error_message(errcode_t 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.

e.g. src/lib/krb5/os/init_os_ctx.c:
374 static krb5_error_code
375 os_init_paths(krb5_context ctx, krb5_boolean kdc)
376 {
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?

Thanks,
Tomas
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Assigning 64-bit errcode_t to 32-bit krb5_error_code

Greg Hudson
On 12/05/2014 05:42 AM, Tomas Kuthan wrote:
> Is there anything (besides common sense) forbidding errcode_t values
> overflowing 32-bit integer?

errcode_t and krb5_error_code are both intended to hold com_err codes,
which are 32-bit values.  A profile plugin module could return a larger
value, but it would be incorrect to do so.

The type "long" was chosen for errcode_t at a time when there were
platforms with 16-bit ints to worry about, and there were no C99
fixed-width types to take advantage of.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev