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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Thu Jul 21 16:34:13 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 ioerror):

 Replying to [ticket:3629 atagar]:
 > Hi Jake. Thanks for this! The only part I'll comment on much is python
 and arm since the change itself mostly concerns the arm deb -> tor deb
 interaction (which treads on areas I'm not too familiar with).

 I was hoping that you would adopt this helper as a thing arm installs on
 more than just Debian. I have used arm on systems that are not Debian and
 it would have been quite helpful there too.

 >
 > See attached for a rewrite of the python script you sent me. Writing
 manual copy methods were unnecessary due to shutil, the group check is
 simplified a bit, and some minor syntax issues would have prevented it
 from running. This checks out with pylint but *I haven't exercised it*
 (not on a good test system).
 >

 It looks better, I agree. I will add some stuff to it today. After
 sleeping on it, I realized that I left a gaping security hole in the file
 copy functions, so I'm going to fix those as much as is possible.

 > My understanding of your change is as follows. I'm sure I'm
 misunderstanding a few parts so corrections appreciated!
 >
 > Step 1: The resources you're providing will only be included or used in
 the arm deb. As such they'll be checked into the packaging branch under...
 > {{{
 > /resources/replaceTorrc/Makefile
 > /resources/replaceTorrc/tor-arm-replace-torrc.c
 > /resources/replaceTorrc/tor-arm-replace-torrc.h
 > /resources/replaceTorrc/replaceTorrc.py
 > }}}
 >

 I was hoping that this would be in your git tree and that it would be part
 of arm. I am submitting it as a general improvement that when arm detects
 it's useful, it will use it. This might be at compile/build/packaging time
 or some other time.

 > Step 2: In deb-prep.sh [1] we'll copy it into release_deb/src/resources
 via something like the following on line 33...
 > {{{
 > (cd resources && git archive --format=tar packaging replaceTorrc) | (cd
 ./release_deb/src/resources && tar xf -)
 > }}}
 >

 I'm not sure I understand what you mean here.

 > Step 3: Also in deb-prep.sh we change our default data directory from
 "~/.arm" to "/var/lib/tor-arm".
 >

 Ah, I'm not suggesting this - I'm only suggesting that if the user is part
 of the "tor-arm" group, then the user uses the system wide arm data
 directory. This is similar to how Tor does things; you can run tor as a
 user or run tor as a daemon system wide. I suspect arm will not be a
 daemon anytime soon but the basic idea is the same: we need a system wide
 arm config where some users can share the auth/other details.

 > Step 4: I build and send debs to Peter as normal, the only difference
 being that the arm deb has these "src/resources/replaceTorrc/*" contents.
 The tor-arm-replace-torrc is still uncompiled at this point.
 >

 If you build a deb, it should have the C wrapper compiled. Peter should
 have to do zero work other than reviewing it, I think. Perhaps not even
 that if we can review it well enough before hand!

 > Step 5: Part of installing the deb is that a "tor-arm" group is created,
 "tor-arm-replace-torrc" is compiled and placed in "<DESTDIR>/bin/tor-arm-
 replace-torrc", and '/var/lib/tor-arm' is made under "root:tor-arm".
 >

 Sure or any time you want to make a system wide user that can use arm in
 this manner, you'd add the user. '/var/lib/tor-arm' needs to be mode 0770
 or something similar, I think.

 > Detail that I'm not clear on: if the user just runs 'arm' then it's
 under their user rather than tor-arm and hence won't be able to access the
 arm data directory, causing arm lots of problems (it won't die, but worse
 performance and many things will not work). Clarification here would be
 nice.
 >

 arm needs to catch this and know that they aren't going to use a
 systemwide config, they're not allowed to do so (or they'd be in the "tor-
 arm" group). This is the case where it should fall back to ~/.arm/ or
 something similar.

 > Step 6: I add an "isDebHack" check which governs if we're gonna be using
 this or not. The conditional is:
 > a. "tor-arm-replace-torrc" is in the PATH
 > b. we're either not connected to tor *or* torrc path for the attached
 instance is "/etc/tor/torrc"

 I'm not sure I'd search the path. I'd only execute it if:
 it's a setuid binary owned by root
 It has the proper group ("tor-arm" or whatever it's configured to be)
 The current users in in the "tor-arm" group
 We have already written a valid configuration file out to
 /var/lib/arm/torrc

 And then the checks you suggest...

 >
 > Step 7: If "isDebHack" is true then when the wizard is finished [2] it
 calls "tor-arm-replace-torrc". If that's successful then HUP tor,
 otherwise show the user an error. This just means a little change around
 line 376.
 >

 That sounds right. This is the change I had hoped you would make.

 > Step 8: My understanding is that the tor process is unable to write to
 its torrc, so SAVECONF calls fail on debian. Is that right? If so, then
 arm's saveConf function [3] will need to be modified so the configuration
 panel can write custom configs.
 >

 Yes, that's correct. If SAVECONF worked on Debian, we would not need this
 at all after our first configuration for authenticate purposes, I think.

 > If this is right then I can do the changes to make arm do the above with
 the exception of step 5. That deb change *and the testing* I'll be leaving
 up to you. My understanding is that this isn't impacting my deb prep
 process and that you're taking ownership of this feature. Please let me
 know if that isn't the case!
 >

 I'm happy to test it but the hook in point seven is probably best coded by
 you. I will provide you with a stable API of fancy unix return codes to
 indicate success or failure.

 I'll change the tor-arm-replace-torrc.py a bit and upload a newer version
 shortly.

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


More information about the tor-bugs mailing list