Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #22331

Closed (moved)
Open
Opened May 23, 2017 by Roger Dingledine@arma

Tor needs to stop trying to read directories before it changes users

If you use apparmor along with the Tor deb, like pretty much all Ubuntu users, and you want to configure a hidden service, you are in for some misery. For example, let's say your put your hidserv directory in /var/lib/tor/, which would make sense because then Tor will create the directory when it starts, take care of its permissions, etc.

The trouble is that the apparmor rules only let the debian-tor user read stuff in /var/lib/tor. They prevent root from trying to read stuff there (because why should it). But when Tor starts, especially Tor 0.3.0.x, it tries to check all the hidden service directories, as root, before it drops privileges. When apparmor refuses the directory read attempts, Tor flips out and says the config is bad: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862993

We should audit all of these cases where we try to interact with files and directories before we've dropped privileges, and get rid of the ones we don't need.

(This one is a little bit tricky, because the way we've set up options_validate() vs options_act(), we'd like to be able to detect if a configuration change is going to fail before we commit to it. But I think cleaning up our behavior here is worth having things fail later because of directory problems if they're going to. After all, this way people will be able to use tight and simple apparmor profiles to enforce good behavior inside Tor.)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#22331