Raise a FATAL error if the user tried to combine v2 and prop224 hidden service in same directory

A user is hosting a hidden service:

Hid /path/to/key/hs-www/ hidport 127.0.0.1:80 80

What will happen if he add "HidVersion V3" line to the middle of the config?

Hid /path/to/key/hs-www/ HidVersion V3 hidport 127.0.0.1:80 80

Tor should detect this misconfiguration and raise an error. (v2 and v3 keys should not exist in same directory)

should be;

Hid /path/to/key/hs-www/ hidport 127.0.0.1:80 80

Hid /path/to/key/hs-www-v3/ HidVersion V3 hidport 127.0.0.1:80 80

changed milestone to %Tor: unspecified

added 034-removed-20180328 034-triage-20180328 component::core tor/tor milestone::Tor: unspecified points::0.3 priority::medium prop224 severity::normal status::new tor-hs type::task labels

Trac:
Summary: Raise a FATAL error if the user tried to combine v3 and v3 hidden service in same directory to Raise a FATAL error if the user tried to combine v2 and prop224 hidden service in same directory

Hm, not sure what's the right behavior here, but given how frequent this behavior must be when upgrading from v2 -> v3 we should think about it. Marking this as 0.3.2 for now, but we can defer it.

Trac:
Points: N/A to 0.3
Keywords: N/A deleted, tor-hs prop224 added
Milestone: N/A to Tor: 0.3.2.x-final

This is already handled. You can't have two hidden services in the same directory path. The configuration process makes sure of that and error with:

Nov 14 07:51:16.145 [warn] Another hidden service is already configured for directory "DIR"

And tor stops. If you were able to make Tor load up with the same HS directory, please tell us how. Closing this for now.

Trac:
Status: new to closed
Resolution: N/A to not a bug

You can just specify the same directory in two different ways, I think:

{{{ HiddenServiceDir /path/abc HiddenServicePort 80 HiddenServiceDir /path/abc/. HiddenServicePort 80 }}

Also, symlinks would let you do that.

Trac:
Resolution: not a bug to N/A
Status: closed to reopened

Oh we aren't sanitizing the input indeed. Do we have anything in tor to do that?

I think it's less input sanitization, and more making sure that the directories aren't actually the same directory. (Consider the symlink case.)

Trac:
Status: reopened to new

Ok btw, we have this in hs_config.c:

  /* XXX: Validate if we have any service that has the given service dir path.
   * This has two problems:
   *
   * a) It's O(n^2), but the same comment from the bottom of
   *    rend_config_services() should apply.
   *
   * b) We only compare directory paths as strings, so we can't
   *    detect two distinct paths that specify the same directory
   *    (which can arise from symlinks, case-insensitivity, bind
   *    mounts, etc.).
   *
   * It also can't detect that two separate Tor instances are trying
   * to use the same HiddenServiceDir; for that, we would need a
   * lock file.  But this is enough to detect a simple mistake that
   * at least one person has actually made. */

So known issue but not that simple to fix.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: 0.3.3.x-final

Pushing this to 034, I think we have more important prop224 stuff to fix. Please put it back in 033 if you disagree!

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

Trac:
Keywords: tor-hs prop224 deleted, prop224, tor-hs, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

changed time estimate to 2h 24m

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