[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