Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • 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
  • #22731
Closed (moved) (moved)
Open
Issue created Jun 26, 2017 by Roger Dingledine@arma

Relative DataDirectory + RunAsDaemon = Tor can't read or write most of its datadirectory files

Bug #22101 (moved) shows a case where if you start your Tor with a relative (non absolute) DataDirectory, and RunAsDaemon 1, and CookieAuthentication 1 but no CookieAuthFile, then Tor will attempt to save your control_auth_cookie file to $datadir/$datadir/control_auth_cookie. (Yes, you read that correctly, $datadir/$datadir/.) The attempt will fail because Tor doesn't mkdir the $datadir/$datadir directory.

If you start with a relative DataDirectory, and RunAsDaemon, but no CookieAuthentication, then your Tor will start, but it will attempt to (and fail to) write each of your datadirectory files -- state, cached-microdescriptors, etc, because it is trying to write them to $datadir/$datadir. I think that might be what teor saw in #20456 (moved), but he doesn't give us an actual torrc so I can't be sure.

The bug is because we call get_datadir_fname(), which creates a filename that prepends $datadir, after we do the chdir($datadir) operation that comes with RunAsDaemon.

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