[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18322 [Core Tor/Tor]: Log unparseable votes so they can be analysed
#18322: Log unparseable votes so they can be analysed
-------------------------------------------------+-------------------------
Reporter: teor | Owner: andrea
Type: defect | Status:
Priority: Medium | needs_revision
Component: Core Tor/Tor | Milestone: Tor:
Severity: Normal | 0.2.9.x-final
Keywords: tor-dos, TorCoreTeam201606, review- | Version:
group-4 | Resolution:
Parent ID: #17293 | Actual Points: 3
Reviewer: | Points: 2
| Sponsor:
| SponsorU-can
-------------------------------------------------+-------------------------
Changes (by nickm):
* status: merge_ready => needs_revision
Comment:
* Don't hate me for this, but: we can't use size_t for the total size of a
bunch of these files, I think. On 32-bit systems, size_t is 4 bytes, but
file sizes can often be 8 bytes.
* We don't have to say "if (foo) tor_free(foo);". Just say
"tor_free(foo)."
* It looks like the dumped descriptor limit is only applied over a
number
* Should these files go into a subdirectory of the datadir? That would
give sysadmins the ability to stick it on another volume, give it
different permissions, etc.
* What do we do about NUL characters?
* Shouldn't we scan the unparseable-desc files at startup, and count how
big they are and when they were last modified? Otherwise we will still up
the disk eventually if Tor stops and starts enough times.
* This approach will break with the linux seccomp2 sandbox, since we
can't predict the filenames in advance. But IMO it'll be fine to just say
"if the sandbox is on, don't store these to disk."
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18322#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs