Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3747 closed defect (fixed)

Tor can't create the ControlPortWriteToFile file if it is to be placed into the not-yet-existant datadir

Reported by: Sebastian Owned by:
Priority: High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

assuming one launches tor like this:

tor DataDirectory /tor ControlPort auto ControlPortWriteToFile /tor/port.conf

and /tor doesn't exist yet, tor will warn that it couldn't write port.conf. It will afterwards happily create /tor, and if you rerun the command everything will work fine. That's kind of weird. We could decide this isn't a tor bug, and any path you pass to ControlPortWriteToFile must exist, but that's a bit inconsistent with our other *File options which will work that way, because they happen to be interpreted after the datadir is created. So I think we should decide this is a tor bug. Why are we opening ports before making our data dir anyway? Due to the need to drop permissions?

Marking this as major as it blocks a new package release with Vidalia 0.2.13

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by nickm

The rationale there is indeed that we want to do the port-binding stuff before we drop privileges, and we want to be poking at the FS as little as possible until _after_ we drop privileges. (For example, if this were running as root and then calling setuid() to "tor-daemon", and we created the data directory as root, then we would create a datadir that "tor-daemon" couldn't read, unless we knew how to chown it, which I don't think we currently do.)

For 0.2.2.x, I think I'd prefer the smallest & most isolated fix that could work. Perhaps, if writing to the file fails, retry it at some later point during the startup process? Or is there something even simpler?

comment:2 in reply to:  1 Changed 8 years ago by rransom

Replying to nickm:

The rationale there is indeed that we want to do the port-binding stuff before we drop privileges, and we want to be poking at the FS as little as possible until _after_ we drop privileges. (For example, if this were running as root and then calling setuid() to "tor-daemon", and we created the data directory as root, then we would create a datadir that "tor-daemon" couldn't read, unless we knew how to chown it, which I don't think we currently do.)

For 0.2.2.x, I think I'd prefer the smallest & most isolated fix that could work. Perhaps, if writing to the file fails, retry it at some later point during the startup process? Or is there something even simpler?

Creating port.conf as root is a security bug -- an attacker with write access to Tor's DataDirectory could put a symlink to /etc/passwd where Tor wants to write port.conf.

comment:3 Changed 8 years ago by nickm

So, how about we delay all "write the port" stuff until some point in the process after setuid, and have it include "create parent directory as needed" ?

comment:4 in reply to:  3 ; Changed 8 years ago by chiiph

Replying to nickm:

So, how about we delay all "write the port" stuff until some point in the process after setuid, and have it include "create parent directory as needed" ?

How much delay would that be? I'm wondering because we already have a "race" between tor starting and Vidalia wanting to connect to the ControlPort.

comment:5 in reply to:  3 Changed 8 years ago by rransom

Replying to nickm:

So, how about we delay all "write the port" stuff until some point in the process after setuid, and have it include "create parent directory as needed" ?

We don't want to 'create parent directory as needed' -- the user may want the list of control ports dumped somewhere other than Tor's DataDirectory, and Tor doesn't normally create parent directories (e.g. HiddenServiceDir /var/lib/tor/hidservs/ssh doesn't work until I create the hidservs and ssh directories). But waiting until after Tor has created its DataDirectory would be sufficient in this case.

comment:6 in reply to:  4 ; Changed 8 years ago by nickm

Replying to chiiph:

Replying to nickm:

So, how about we delay all "write the port" stuff until some point in the process after setuid, and have it include "create parent directory as needed" ?

How much delay would that be? I'm wondering because we already have a "race" between tor starting and Vidalia wanting to connect to the ControlPort.

Far less than a second, I'd expect.

(And if there's already a race, then Vidalia already needs a solution.)

comment:7 in reply to:  6 Changed 8 years ago by chiiph

Replying to nickm:

Far less than a second, I'd expect.

(And if there's already a race, then Vidalia already needs a solution.)

Yes, right now it tries 5 times waiting a second after each one.

Right now, I've experienced a delay of 1 or 2 seconds on an Ubuntu VM before it creates the port file, so this idea of delaying the creation may take more than a second on a slow system.

comment:8 Changed 8 years ago by nickm

Status: newneeds_review

See branch bug3747 in my public repository.

comment:9 in reply to:  8 Changed 8 years ago by rransom

Replying to nickm:

See branch bug3747 in my public repository.

Looks good!

comment:10 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

ok; merged to 0.2.2 and master

comment:11 Changed 7 years ago by nickm

Keywords: tor-client added

comment:12 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.