Difference between revisions of "Projects/Trace logging"
From K5Wiki
< Projects
(→Selecting Trace Information) |
(→Selecting Trace Information) |
||
| Line 11: | Line 11: | ||
* It should be possible to explicitly disable the facility at compile-time for embedded deployments or kernel code. |
* It should be possible to explicitly disable the facility at compile-time for embedded deployments or kernel code. |
||
| − | ==Selecting Trace Information== |
||
| + | ==User Interface== |
||
| − | To begin with, tracing will be a binary switch--all tracing information or none of it. If the volume of trace logging information for common operations becomes overwhelming, this can be refined by adding tracing levels or tracing categories. |
||
| + | To turn on tracing, the user will set the KRB5_TRACE variable to a filename. This will not work for secure contexts. |
||
| + | |||
| + | To disable tracing at compile time, the builder will specify --disable-tracing to configure. |
||
==Implementation concerns== |
==Implementation concerns== |
||
Revision as of 20:11, 11 September 2009
This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.
Background
Multiple users of Kerberos have expressed a desire for logging to assist in the diagnosis of configuration failures. As a secondary benefit, such a facility may also be useful for debugging work by Kerberos developers. Requirements include:
- It is sufficient to be able to be able to log to a file specified by an environment variable.
- It is important that it be possible to enable trace logging in a standard build, such as the one shipped by the operating system vendor, because it is generally not possible to substitute specially compiled code in a customer deployment.
- The facility must not compromise the security of setuid programs by allowing the invoking user to leak information or write log files using elevated privileges.
- The facility must have a minimal impact on performance when not enabled.
- It should be possible to explicitly disable the facility at compile-time for embedded deployments or kernel code.
User Interface
To turn on tracing, the user will set the KRB5_TRACE variable to a filename. This will not work for secure contexts.
To disable tracing at compile time, the builder will specify --disable-tracing to configure.
Implementation concerns
The biggest decision here is whether trace calls require a context. If so:
- Thread safety is easier (a log file handle can be cached in the context).
- The mechanism can be disabled for setuid programs via krb5_init_secure_context.
- A macro can elide the function calls when trace logging is not enabled, saving a few cycles.
- APIs could be provided to turn tracing on and off, or direct different contexts to different files. (However, API control of tracing is not a requirement.)
If not:
- Code which does not have a context available can be traced.
- Cached information must be global, and therefore locked, probably with some kind of cheat to minimize the performance impact when disabled.
- Trace calls become less verbose.
- The implementation can live in libkrb5support instead of libkrb5.
- The facility might be more friendly to plugin code living in our tree.
