thoughts/issues making MIT krb code fit for drop-in to Solaris
raeburn at MIT.EDU
Fri Sep 19 00:53:13 EDT 2008
On Sep 17, 2008, at 20:04, Will Fiveash wrote:
> One goal Sun has in regards to it's association with the MIT Kerberos
> Consortium is to eventually have the Consortium's Kerberos source code
> made suitable to use as is in Solaris (drop-in). This would save Sun
> time and effort in that resync'ing the Consortium's source code with
> Solaris Kerberos source code could be avoided.
Overall, I think it's a good idea for us to incorporate changes that
improve the library for everyone, or make it easier to integrate
without making it harder for us to maintain. On first read-through,
here are some of my initial observations:
> One approach suggested by Nico Williams is to do this by modifying one
> MITKC component at a time to keep each project smaller in scope. The
> following components would be updated in an order like:
> - Crypto Framework
> Solaris Kerberos uses the native Solaris Encryption Framework
> interfaces for it's crypto needs in both user and kernel space.
> This mainly involves changes to files under src/lib/crypto. Note
> that the _krb5_keyblock has also been modified:
I believe our intent from the introduction of krb5_init_keyblock was
to move towards dynamic allocation of keyblock structures in the
library, which structures would be extended with additional fields not
visible to the caller; other code would distinguish the two kinds via
the magic number field. Allocating the structure in the caller would
probably be considered deprecated (but still supported, for backwards
compatibility). Additional fields could include key schedules, cached
derived keys, stuff like that.
We haven't really pushed forward on the idea beyond introducing the
new allocation function.
> - I18N, error tables and messages in general.
> MIT dynamically generates their error tables, Solaris uses a static
> switch statement in various C files based on the MIT error tables.
> For example, in OpenSolaris there is this code in
The KfM code already has i18n support in the error table handling, so
ideally we'd extend the UNIX com_err code in a similar fashion.
Handling of the domain names is an interesting question -- since
error_message needs to figure out the right domain name to use, and
error tables in different libraries may have been installed by
different packages (it's not widely used, but there are other things
besides krb5 using com_err), the domain name probably needs to be
independent of the library and associated just with the error table
name or values, unless we want to require use of brand new com_err APIs.
> Also Solaris calls gettext() to translate various non-error table
> messages. Anyway, this is an area that we need to research further
> to find a reasonable solution.
Yeah. I'm not sure what the best answer's going to be for Windows,
where (from a couple of things I've read) I think the LoadString
function is the usual interface, but it wants an integer key, not a
string, and the domain-name equivalent is a module handle returned
from another function call. But otherwise I think gettext, or a
wrapper around it (to allow for indirection to other mechanisms, or
filling in no-ops for lame systems or for intentionally disabling it),
is probably going to be the answer we want.
> - Zero Conf realm lookup changes
> Support of a fall back default realm based on the host's domain
> if the default realm is not specified in the krb5.conf.
Yes, we were talking about this the other day. I think the patch I
was remembering that Mark sent in does something a bit different
though. I still should see about pulling some of that code in though.
> - No reverse DNS lookup in krb5_sname_to_principal()
This will be a behavioral change. We should also not be doing the DNS
lookup to canonicalize the name in the first place, but fixing that
requires other support (having the KDC recognize aliases, etc); that
will also be a behavioral change. I think we've been maintaining the
status quo until we can inflict just one massive change on the end
sites instead of two.
More information about the krbdev