Opened 7 years ago

Last modified 3 months ago

#1802 new defect

ControlPort GETCONF does not recognize command aliases

Reported by: cjb Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client controller alias easy
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Because commands passed to GETCONF are not looked-up in the aliases table with expand_abbrev(), we reject GETCONF requests for options that would be valid (though deprecated) if they were used in a torrc.

For example, GETCONF AllowInvalidNodes works whereas GETCONF AllowUnverifiedNodes fails. AllowUnverifiedNodes is a deprecated alias for AllowInvalidNodes.

I propose fixing this by having handle_control_getconf() first call expand_abbrev() on the option it's going to look up. I'll attach a patch that does that for review.

Child Tickets

Change History (14)

comment:1 Changed 7 years ago by nickm

I'm worried about doing anything that enshrines deprecated config names (especially prefix-based aliases). We'd like to be able to remove these things someday.

What's the rationale on this one? Why can't the controller use the real option names?

comment:2 Changed 7 years ago by cjb

What's the rationale on this one? Why can't the controller use the real option names?

I'm confused by your use of "the controller"; I think I *am* trying to modify the controller (or/control.c:handle_control_getconf()) to perform that lookup so that it can use the real option names.

I think you must be instead asking "Why can't an application (in this case, arm) using the Tor controller pass real option names to the controller?", and some possible answers are:

  • the application could have been developed before the option name it's interested in was deprecated, or
  • the application would like to be able to assume that a running torrc contains real option names, so that it doesn't have to carry around option name mappings, which would just become stale, leading back to the last bullet point.

I think I must still be missing something about your comment, though -- could you elaborate?

comment:3 Changed 7 years ago by nickm

The controller is not control.c; the controller is the program that uses the control port to control Tor.

comment:4 Changed 7 years ago by cjb

Summarizing IRC conversation:

  • Nick isn't okay with expanding abbreviations for controllers, just aliases.
  • That sounds okay to cjb.
  • Atagar's worried that he's going to end up emitting warnings into the Tor log each time a controller tries to refresh current settings from a torrc. (Maybe that should get a different bug.)

comment:5 Changed 7 years ago by atagar

Yup, that's definitely a separate issue and I've never met someone that used abbreviations in their torrc so I'm not too concerned about it. Cheers! -Damian

comment:6 Changed 7 years ago by nickm

Rate-limiting the warnings seems okay, as does emitting each one at most per torrc reload.

comment:7 Changed 7 years ago by atagar

Separate ticket created for that issue:
https://trac.torproject.org/projects/tor/ticket/1806

comment:8 Changed 7 years ago by arma

cjb, atagar: does that mean this trac is closable?

comment:9 Changed 7 years ago by nickm

arma: I think the answer is "no"; they're still hoping for the aliases table (but not the general abbreviation mechanism) to get used for getconf/setconf, and I don't think it is.

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:11 Changed 6 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:12 Changed 5 years ago by nickm

Keywords: tor-client added

comment:13 Changed 5 years ago by nickm

Component: Tor ClientTor

comment:14 Changed 3 months ago by nickm

Keywords: controller alias easy added
Priority: MediumLow
Severity: Normal
Note: See TracTickets for help on using tickets.