Trace logging project

[Greg Hudson]

Thanks for the feedback.  I have a little follow-up on one of your
requirements:

On Sat, 2009-09-12 at 19:23 -0400, JC Ferguson wrote:
> - The trace logging must be able to be enabled and disable without
> restarting a program that calls MIT KRB5.  We have long-running
> programs and it would be disruptive to restart the program to enable
> logging, then restart it again to disable logging.

I've been thinking about how we might support dynamic enabling/disabling
of tracing without impacting performance.  As a library, we have limited
choices for dynamic interaction with the outside environment (we can't
commandeer signals, for instance), so the basic question is whether we
can consult the filesystem at a regular enough interval to enable
tracing promptly, but not too often.

On the wiki discussion page, you suggested using krb5.conf accesses as
an integration point.  I'm not sure that's quite a proper fit.  As
things are now, we can't be sure that krb5.conf would be accessed
frequently enough to turn tracing on and off promptly; also, in the
future, performance considerations may lead us to access krb5.conf less
frequently than we currently do.  (Heimdal, for instance, only reads in
krb5.conf at context initialization, and is generally more parsimonious
with its internal use of krb5 contexts than we are.)

One option is to tie into a subset of APIs which might serve as a
heartbeat.  For applications which regularly establish security
contexts, the combination of krb5_mk_req and krb5_rd_req might serve;
they usually have to do filesystem accesses to retrieve keys anyway.
For applications which use a single security context for a long time
(such as ssh), I'm not sure if there are any good options--adding a
filesystem access to every sign/seal operation might be too much.

My other thought is that one might have to explicitly turn on dynamic
enablement/disablement of tracing in krb5.conf, such that the filesystem
access penalty would only be paid for in environments which need it.

As you noted, we always have the option of punting this problem to the
application.  Applications have a better range of choices when it comes
to IPC, as well as more information about what performance tradeoffs are
reasonable.  But of course this places more of a burden on the
application, and it is also not useful in situations where someone wants
to dynamically enable tracing in an application they didn't write.