Make log granularity configurable

It would make Tor slightly more resistant to post-facto debug log compromise attacks if the times displayed on log entries were more fine-grained. For some kinds of debugging, we do indeed want our current millisecond resolution, but it would be neat if that only happened when you configured "LogTimeGranularity 1msec". A better default might be 1sec or 5sec.

changed milestone to %Tor: post 0.2.2.x

added component::core tor/tor easy milestone::Tor: post 0.2.2.x priority::very low resolution::implemented status::closed tor-relay type::enhancement labels

Trac:
Keywords: N/A deleted, easy added

I implemented something in branch loggranularity in my public repository.

Trac:
Status: new to needs_review

Trac:
Cc: N/A to Sebastian, ln5

Trac:
Cc: Sebastian, ln5 to Sebastian, ln5, ioerror

Trac:
Milestone: N/A to Tor: post 0.2.2.x

I just rebased my branch loggranularity to master and pushed it to my public repository (forced update). Please review and merge into master.

Looks good. A couple of things to change/think about:

• Instead of rejecting a value that doesn't divide into 1 second, can we round to the nearest divisor of 1 second and warn?
• Actually, there are only 15 divisors of 1 second that you can express as an integer number of msec. Is this too restrictive? Too permissive? Is there any good reason for anyone to set something bigger than 1msec but smaller than 1sec?
• The code should document that the option only controls the granularity written by Tor to a file or console log. It does not (for example) "batch up" log messages to affect times logged by a controller, times attached to syslog messages, or the mtime fields on log files. I think this is okay, but we should document it so nobody gets surprised.

Replying to nickm:

Looks good. A couple of things to change/think about:

• Instead of rejecting a value that doesn't divide into 1 second, can we round to the nearest divisor of 1 second and warn?

Sure. I changed the code so that we pick the next higher valid divisor or multiple: 3 msec -> 4 msec, 126 msec -> 200 msec, 1001 msec -> 2000 msec. We're still rejecting negative values, though.

• Actually, there are only 15 divisors of 1 second that you can express as an integer number of msec. Is this too restrictive? Too permissive? Is there any good reason for anyone to set something bigger than 1msec but smaller than 1sec?

Hard to say. My idea was to be as permissive as possible. But things went ugly (and probably unexpected for the user) when allowing 400 msec or something.

• The code should document that the option only controls the granularity written by Tor to a file or console log. It does not (for example) "batch up" log messages to affect times logged by a controller, times attached to syslog messages, or the mtime fields on log files. I think this is okay, but we should document it so nobody gets surprised.

Right. I added a comment like yours to the man page.

See updated branch loggranularity in my public repository.

Looks better. Merging. Thanks!

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

Trac:
Keywords: easy deleted, easy tor-relay added

Trac:
Component: Tor Relay to Tor

closed

moved to tpo/core/tor#1668 (closed)