tracing icon indicating copy to clipboard operation
tracing copied to clipboard

tracing-subscriber: impossible to completely disable an event with a static filter if dynamic filters can enable it

Open tfreiberg-fastly opened this issue 2 years ago • 0 comments

Bug Report

Version

tracing v0.1.34 tracing-subscriber v0.3.11

Platform

$ uname -r
21.5.0

(MacOS 12.4)

Crates

tracing-subscriber

Description

We have an event that logs sensitive data, which we want to keep disabled by default (it's only supposed to be enabled manually in rare situations) This event uses a specific target not prefixed by the crate name and our EnvFilter is initialized with this target set to off. Unfortunately, since the event is inside an #[instrument] with several fields, dynamic filters including this field can enable the event (since dynamic filters ignore the target of the event and instead only evaluate the target of the span, correct?)

Example:

(e.g:

// lib.rs in crate `cache`
#[instrument]
fn lookup(id: &str, headers: &Headers) {
  trace!(target: "sensitive", ?headers);
  trace!(?id, "lookup);
  // ...
}

RUST_LOG=cache=trace ./cache properly only logs the lookup id, but RUST_LOG=cache[lookup{id=ABCDEF}]=trace ./cache also logs the sensitive

This means that there doesn't seem to be a way to disable events completely via tracing filters as long as they can be in a span, right?

There are of course possible workarounds such as putting that event behind a feature flag (would require recompilation and a restart to log those fields, but it's very safe. some colleagues do that), or runtime configuration other than tracing filters.

This is a similar issue to https://github.com/tokio-rs/tracing/issues/1388 (only the other way around), so maybe you don't want to change this, but the interaction between dynamic and static filters seems a bit surprising at times.

tfreiberg-fastly avatar Jun 20 '22 09:06 tfreiberg-fastly