Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#1668 closed enhancement (implemented)

Make log granularity configurable

Reported by: nickm Owned by:
Priority: Very Low Milestone: Tor: post 0.2.2.x
Component: Core Tor/Tor Version:
Severity: Keywords: easy tor-relay
Cc: Sebastian, ln5, ioerror Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (11)

comment:1 Changed 9 years ago by nickm

Keywords: easy added

comment:2 Changed 9 years ago by karsten

Status: newneeds_review

I implemented something in branch loggranularity in my public repository.

comment:3 Changed 9 years ago by karsten

Cc: Sebastian ln5 added

comment:4 Changed 9 years ago by karsten

Cc: ioerror added

comment:5 Changed 9 years ago by Sebastian

Milestone: Tor: post 0.2.2.x

comment:6 Changed 9 years ago by karsten

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

comment:7 Changed 9 years ago by 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?
  • 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.

comment:8 in reply to:  7 Changed 9 years ago by karsten

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.

comment:9 Changed 9 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Looks better. Merging. Thanks!

comment:10 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:11 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.