[660] in Kerberos_V5_Development
krb5 error code numeric values -- are they architectural?
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Thu Mar 28 18:04:31 1991
Date: Thu, 28 Mar 91 17:46:27 EST
From: sommerfeld@apollo.com (Bill Sommerfeld)
To: krbdev@ATHENA.MIT.EDU, raeburn@ATHENA.MIT.EDU
Cc: dce-tech@osf.org
The tale of two error code systems...
Kerberos v5 uses the MIT comerr package for error code management;
this is essentially the same package used by AFS3.
Comerr uses error codes encoded in the form:
TTTTTTEE
where TTTTTT is the error table name, which is a four-character string
encoded at 6 bits per character, and EE is the error code within the
error table
The DCE has adopted a slightly different encoding:
FCCCCEEE
where "F" is a facility code assigned by the osf OSF, CCCC is the
Radix-50 [1] encoding of a three character component name, and EEE is the
error code within the table.
Other than the format of the error codes, the two systems are
remarkably similar in how they are used in an application.
Now, there are two different kinds of error codes: API error codes,
and "architectural" error codes. API error codes have to be
consistent within a single implementation, but they can be changed
from implementation to implentation without affecting
interoperability. Architectural error codes, on the other hand, have
to have the same bit pattern in all implementations without affecting
interoperability.
Kerberos is being used in the DCE, although it is hidden from pure DCE
applications under a different API, but it is there "under the
covers", and could conceivably be "made public" in the future.
It would be useful to the DCE if, in the DCE, the kerberos
implementation used error codes in the DCE error space; this would
eliminate the need to translate between the two spaces.
Kerberos is fairly careful to make this distinction in the error codes
returned by the KDC, so, within the kerberos library and protocol,
there appears to be no problem with doing this, and a "pure MIT"
version of kerberos should interoperate with a modified DCE version
with no difficulty.
However, there are a number of athena appliations which use comerr
codes "on the wire" (I should know, I helped write some of them before
I knew better...). If one of these is built against the DCE
implementation, it will not interoperate with one built against the
MIT version of the library.
----
Now, there are two solutions to this problem:
1) the kerberos v5 api can be spec'ed that the values of error codes
are subject to change across implementations, and should not be passed
"over the wire", thus rendering any application which uses them over
the wire technically in violation of the spec.
If MIT is unwilling to make this assertion (which could require
wire-protocol level changes to a fairly significant installed base of
applications at MIT -- but then, moving from v4 to v5 will cause
similar chaos), we can fall back to option 2:
2) the DCE kerberos implementation uses the comerr-space errors, and
maps kerberos error codes to DCE error codes at some point in between
the kerberos API and the DCE API. This is actually relatively trivial
to do, as the various error tables used by kerberos will be adopted in
to the DCE error space.
Either answer is fine with me; I'd prefer (1), but can live with (2).
- Bill
[1] For those unfamilar with DEC operating systems: Radix-50 is a way
of encoding letters, numbers, and a very limited set of punctuation in
base-40, at three characters to two bytes. It's know as "Radix-50"
because 40 decimal is 50 octal ...
