Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #16288

Closed (moved)
(moved)
Open
Created Jun 03, 2015 by David Goulet@dgoulet🆘

The open file limit is not checked before calling tor_accept_socket_nonblocking()

Tor keeps a buffer amount of file descriptor to avoid running out when trying to do critical operation such as updating crypto keys or saving the state file. See ULIMIT_BUFFER for this which is set to 32. For example, if the system running tor is allowed to open 4096 files, only 4064 of them will be used for network connections.

The tor_accept_socket_nonblocking() call is done in connection_handle_listener_read() which creates a new file descriptor from a listener connection but the open file limit is currently not checked before. Because of that, we accept connection well beyond our limit (set in ConnLimit_) which is bad because if we ran out, we can't update for instance our ed25519 keys which results in a violent exit() :).

I propose we put the open file limit just before we call socket(), in tor_open_socket_with_extensions() and in tor_accept_socket_with_extensions(). This way we centralize the limit check and avoid future issues when adding a new open/accept socket call.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking