[1362] in Kerberos_V5_Development
Re: kadm5 api, krb5_tl_data, type number assignment
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Jun 29 13:10:07 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: tytso@MIT.EDU, krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 29 Jun 1996 13:09:57 -0400
In-Reply-To: "Barry Jaspan"'s message of Thu, 20 Jun 1996 12:21:31 -0400
>>>>> "bjaspan" == "Barry Jaspan" <bjaspan@MIT.EDU> writes:
bjaspan> I'd suggest dumping [the krb5_tl_data stuff] in in
bjaspan> libkrb5util. I'm a bit concerned that libkrb5util is
bjaspan> turning into a dumping ground, but libkrb5 doesn't seem
bjaspan> to be the right place for it, either.
bjaspan> I don't understand the motivation for libkrb5util at all.
bjaspan> Adding extra functions to a library does not increase
bjaspan> executable size unless the functions are actually used.
bjaspan> Moving functions from libkrb5 to libkrb5util does not
bjaspan> save disk space, either, since the .o files still exist,
bjaspan> just in a different place. The only argument I can see
bjaspan> behind libkrb5util is to save time running ar and ranlib,
bjaspan> but that is a pretty thin excuse given that it will
bjaspan> confuse users to have to link against Yet Another
bjaspan> Library.
It helps shared libraries significantly if we don't have to
deal with circular dependencies. Currently, libkrb5util contains the
compat_fooauth routines so that libkrb5 doesn't depend on libkrb4,
which already depends on libkrb5.
I think libkrb5util came out of a discussion in which we were
considering creating a set of utility procedures that were not part of
the API but would be useful within the MIT applications. The
krb5_seteuid function is an excellent example; it's currently only
used by ksu, but that will change once I get my hands on login.krb5 (I
think I see a race condition, and chown is almost always the wrong
answer anyway.)
If we decide not the export the krb5_compat_(send|recv)auth
routines, then I would argue that everything in krb5util belongs
there. Unfortunately, I think we *do* export these interfaces.
However, I really don't want to move them into krb5 or krb4.
Truthfully, though, krb5util is another area where something
needed to be done in the short term, and it's not clear that the best
long-term solution was adopted.
bjaspan> On a separate but related topic, Marc has made the
bjaspan> following suggestion for the name space of krb5_tl_data
bjaspan> tl_data_type values:
bjaspan> 0 <= x < 256 reserved for internal use MIT 256
bjaspan> <= x < 32768 should only be used if registered with MIT
bjaspan> 32768 <= x < 65536 application-defined
bjaspan> Applicaiton-defined makes no sense; I assume you mean
bjaspan> "site-defined"?
bjaspan> "Application-defined" means that an application client
bjaspan> and/or server simply chooses a constant value for the
bjaspan> krb5_tl_data type to use, with no guarantees that it will
bjaspan> not conflict with other application-defined values. Any
bjaspan> decent implementation would allow for the value to be
bjaspan> configurable, probably through krb5.conf... which I guess
bjaspan> means that applicatin-defined and site-defined are sorta
bjaspan> the same thing in this case, yes. :-)
bjaspan> Barry
