[krbdev.mit.edu #8630] Logging from KDC/kadmind plugin modules

[Greg Hudson via RT]

One candidate improvement is to add a logging callback to the 
kdcpreauth interface with the same signature as krb5_klog_syslog(), 
and phase out the use of com_err() in kdcpreauth modules.  This 
option does not address other KDC pluggable interfaces like certauth 
and kdcpolicy, but perhaps modules for those interfaces won't have a 
problem linking against libkadm5srv if they need to log.  
krb5_klog_syslog() doesn't have a convenient shorthand for logging 
errors like com_err() does; we could add a second callback wrapper 
for that, or leave it up to modules to decide what to do about logs 
resulting from errors with associated com_err codes.

Another candidate improvement is to clean up the com_err() logging 
behavior and use it more consistently in modules.  For this line of 
approach:

* The whoami value should be consistently used or ignored.  Ignoring 
it is the simplest option, as the logging framework already has a 
whoami value given at initialization.  The OTP calls to com_err() 
would need to be changed to take into account that the whoami 
argument ("otp") won't appear in the log message.

* Taking a severity specification in the first byte of the format 
string could probably be removed for code cleanliness.

* The "default severity" could probably be removed.  The com_err 
handler could log at LOG_ERR severity if a non-zero code is given and 
LOG_INFO severity if the code is zero.  That is somewhat limiting (no 
ability to issue LOG_WARN severity messages).

* We could make extended error messsage work by adding a libkadm5srv 
interface to set the value of err_context (used by the logging 
com_err handler and currently only set at krb5_klog_init() time), and 
making the KDC set err_context to the per-realm krb5_context object 
for each request.  That's not very satisfactory, but it's the only 
real option given that com_err() doesn't accept a krb5_context 
parameter.  (err_context could also be made a thread-local variable, 
but that's not an immediate concern.)