[tor-bugs] #3629 [arm]: Arm/Tor Deb Torrc Configuration

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Fri Jul 22 16:39:03 UTC 2011


#3629: Arm/Tor Deb Torrc Configuration
-------------------------+--------------------------------------------------
 Reporter:  atagar       |          Owner:  ioerror
     Type:  enhancement  |         Status:  new    
 Priority:  normal       |      Milestone:         
Component:  arm          |        Version:         
 Keywords:               |         Parent:         
   Points:               |   Actualpoints:         
-------------------------+--------------------------------------------------

Comment(by Sebastian):

 Replying to [comment:2 atagar]:
 > > I was hoping that you would adopt this helper as a thing arm installs
 on more than just Debian.
 >
 > Woah, that changes this. Just to make sure I'm understanding this right,
 you want arm's install script to automatically execute gcc on the user's
 system? If so then this is the first I've ever heard of an installer doing
 compilation on an end user system...

 install-time compilation doesn't make sense. But I don't think this is
 what was proposed here? I took it as build-time compilation, which is
 standard

 > If this was just for Debian then I'd be happy to go with pretty much any
 hack you and Peter wanted, but if this is for arm in general then I'm much
 more concerned. It's a pity the setuid bit is specifically disabled on
 most systems for shell scripts. I'd find that much less objectionable.

 suid root scripts are generally a sad thing from experience

 > My feeling is this:
 > - If Tor decides to have root permissions on its torrc then Tor is
 clearly indicating that they want it to only be hand edited. Personally I
 think this is dumb since it breaks SAVECONF and hurts users, but oh well.
 Controllers (both arm and Vidalia) should treat this torrc as being kinda
 useless and work around it.

 Tor doesn't decide this. It is whoever is packaging Tor that makes the
 decision. Personally I think it is a great idea, I find it horrible that
 some kind of networking daemon with the power of Tor should have the power
 to change its own configuration. This is, as far as I know, only
 implemented as a hack so that controllers on remote systems can work and
 change the configuration persistently.

 > - When I scripted arm's setup wizard I took the same tactic as Vidalia,
 making a torrc in my own data directory for an arm managed Tor instance.
 If fixing the permissions on the system torrc and editing the init.d
 script are both forbidden then the only real option left to controllers is
 to ignore those and make their own.

 I feel like this is a good approach for a TBB-like client instance. I'd
 never want to run a relay like that, just for port opening reasons and
 resource consumption etc.

 > - This setuid hack is in effect the same as a chown on the system torrc.
 That in itself I'm fine with (assuming Nick was on board). However, this
 is introducing an extremely ugly song-and-dance for working around Tor's
 permission issue and, in my opinion, end user compilation pushes the hack
 way too far. If we think that this hack is ok then we should just skip the
 overly complicated workaround and issue what's in effect a chown directly.

 I think nick doesn't have anything to do with it - it's a packaging
 decision. (I don't mean nick won't have a useful opinion here, just that
 this is not something that Tor decided to do a certain way).

 > All this said, if others in the community really think that this is the
 best route forward then I'll bite the bullet in the name of
 interoperability. Sebastian, Nick: what are your opinions?

 I think the only sane way forward is to prompt for root when a root-owned
 file is supposed to be overwritten

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3629#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list