kdc "status" - string or number

[Greg Hudson]

On Wed, 2010-02-03 at 16:29 -0500, Zhanna Tsitkova wrote:
> I suggest to make “status” an integer and use com_error tables to  
> translate them into the meaningful strings when needed.

Taking a step back:

The fundamental problem is that there are two views of an AS or TGS
error: the protocol error code, such as KDC_ERR_POLICY, which is limited
to the set of RFC 4120 error codes, and the specific problem, like
"renewable tickets requested but not allowed by the {client/server}
principal".  Currently we use errcode (a krb5_error_code) to describe
the former, and status (a string literal) to describe the latter.
(Well, more or less.  If errcode is not one of error codes corresponding
to RFC 4120 errors, we map it to KRB_ERR_GENERIC, and this happens in
some cases.)

We could use krb5_set_error_message on the protocol error code to
eliminate the need for the status string, but that assumes we still want
the specific problem to be represented as a string.  That would be no
more friendly to an audit system than the current design.

Zhanna's proposal is essentially to carry around two numeric error
codes--one for the the protocol error code and one for the
implementation-specific description of the problem.  To address Sam's
concern, we could still use krb5_set_error_message on the KDC-internal
error code to generate more complete descriptions of problems.

An alternative proposal would be to use KDC-internal error codes
everywhere, and have a big function or table which maps them onto
protocol errors.  That design would simplify the error-handling code
within the KDC, at the expense of having a long-range correspondence
between the set of error codes used in the KDC (and subsidiary
libraries) and the protocol error code map.

> 2.    Keeping English strings in the fewer places simplifies  
> localization of the error messages/logs

We don't have to collect all of the English strings together to do
localization; the usual practice in open source projects is to use
xgettext to extract English strings from source files into message
catalogs.

The audit system justification is sufficient to make some kind of
change, though.