[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3629 [arm]: Arm/Tor Deb Torrc Configuration
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs