tor --verify-config should not bind to ports

https://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html

maybe we can also get rid of the 'requires root privileges' - thing? https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.html

changed milestone to %Tor: 0.3.4.x-final

added bootstrap component::core tor/tor configuration intro milestone::Tor: 0.3.4.x-final owner::rl1987 priority::low refactor resolution::worksforme reviewer::catalyst severity::normal startup status::closed technical-debt tor-relay torrc type::defect labels

Trac:
Milestone: N/A to Tor: 0.2.7.x-final
Keywords: N/A deleted, tor-relay added

Hrm, this depends a little on how much verification we want to do. We can either say "this config file parses, we're good" or we can say "we can actually apply all the settings in the config file". I'm leaning towards the former, which indicates this is a bug, but maybe others think it's the latter in which case we should improve the docs.

Is anything but luck preventing this problem in the current debian init.d scripts?

(they also call check_config() before starting tor)

Trac:
Username: tyseom
Cc: N/A to nusenu@openmailbox.org

Trac:
Username: tyseom
Cc: nusenu@openmailbox.org to N/A

Trac:
Status: new to assigned

Marking triaged-out items from first round of 0.2.7 triage.

Trac:
Keywords: N/A deleted, 027-triaged-1-out added

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Trac:
Keywords: N/A deleted, intro added

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal
Points: N/A to small

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Should a new option (such as --parse-config) be added for the more minimal step of parsing only and --verify-config left as is to preserve compatibility? Or is it okay to change the behavior of --verify-config directly?

Trac:
Username: jryans
Reviewer: N/A to N/A

Hmm, there are two different use cases here:

1. I am not running a relay, and I'm about to start one, and I want to know if it will work,
2. I am running a relay, and I'm about to change the config, and I want to know if it will work

We can bind to ports in case 1), but not case 2).

I think we should add a new option --parse-config that just does an options_verify(). Of course, the risk is that it will succeed, and then when it gets to options_act(), it will fail because it suddenly finds out it can't do what it wanted to do.

But for --verify-config, the risk is that it will fail unnecessarily, because it could do the things if only it were the existing tor process.

Trac:
Username: jryans
Cc: N/A to jryans@gmail.com

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: N/A deleted, 027-triaged-in added

Trac:
Keywords: 027-triaged-in deleted, N/A added

Trac:
Keywords: 027-triaged-1-out deleted, N/A added

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

Trac:
Status: assigned to new

Trac:
Keywords: N/A deleted, technical-debt, refactor, bootstrap, torrc, configuration, startup added
Priority: Medium to High

Trac:
Owner: N/A to rl1987
Status: new to assigned

Added --parse-config CLI option:

• https://github.com/rl1987/tor/compare/ticket15015

Trac:
Status: assigned to needs_review

Thanks for this patch.

The code looks good, but I think we can improve the man page:

• please put parse-config immediately after verify-config
• please explicitly document the different use cases for verify and parse:
  • verify may fail if the tor service is already running
  • parse should be used if the tor service is running

If you'd like, you can also set up Travis CI on your branch, or open a pull request on https://github.com/torproject/tor https://trac.torproject.org/projects/tor/ticket/23883#comment:3 It's the first thing the next reviewer will do.

Trac:
Points: small to N/A
Status: needs_review to needs_revision
Milestone: Tor: unspecified to Tor: 0.3.4.x-final

Pushed c1c5970ac83ad804739bd2515b297195df927956 that improves the manpage.

Trac:
Status: needs_revision to needs_review

Thanks. Looks good to me.

I'd like someone else to review this next, and check it against CI. They can decide if we need unit test scripts for --parse-config and --verify-config.

Trac:
Reviewer: N/A to catalyst

Thanks for the patch! The code looks good. Like teor, I wonder if tests are needed.

Right now I'm not sure whether the originally reported problem still exists. I can't seem to get a "permission denied" error when setting SOCKSPort 88 on the command line with --verify-config on master, even though I do get that error without the --verify-config option.

Trac:
Status: needs_review to needs_information
Priority: High to Low

No one I've asked seems to be able to reproduce this on a modern tor. There's some evidence that such a bug might have existed back before 0.2.0, but it seems like it's gone in supported releases.

rl1987, thanks again for working on this patch. I'm sorry it turns out to be unnecessary.

Trac:
Status: needs_information to closed
Resolution: N/A to worksforme

closed

moved to tpo/core/tor#15015 (closed)