Difference between revisions of "Projects/Trace logging"
From K5Wiki
< Projects
(New page: {{project-early}} ==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 faci...) |
(→Selecting Trace Information) |
||
| Line 13: | Line 13: | ||
==Selecting Trace Information== |
==Selecting Trace Information== |
||
| − | There are four basic possibilities here: |
||
| + | 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. |
||
| − | |||
| − | # Tracing could be a binary switch. You get everything or nothing. |
||
| − | # Information could be selected by a number, a la the "debug level" of other projects. A higher number causes tracing in greater detail. |
||
| − | # Information could be selected by a combination of topic keywords. |
||
| − | # (2) and (3) could be combined, perhaps with a separate logging level for each keyword. |
||
| − | |||
| − | Filtering can be done on the logs after the fact, so more complexity may just add to the verboseness of trace calls without adding much value. |
||
==Implementation concerns== |
==Implementation concerns== |
||
Revision as of 19: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.
Selecting Trace Information
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.
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.
