new identity feature could support ControlSocket

New identity feature only supports ControlPort. Supporting ControlSocket as well would make it easier to integrate with Debian systems that have Tor 0.2.2.x with ControlSocket enabled by default.

added AffectsTails component::applications/torbutton owner::mikeperry priority::low resolution::duplicate severity::normal status::closed type::enhancement labels

Trac:
Cc: N/A to amnesia@boum.org

Trac:
0001-Implement-NEWNYM-through-ControlSocket.v0.patch

Implement NEWNYM through ControlSocket (v0 patch)

I have just attached a first working attempt of implementing NEWNYM through ControlSocket.

This is a very crude hack using js-ctypes but it is working nevertheless. It currently hardcode almost everything, but I'd like to have Mike's opinion before improving this very first attempt.

Trac:
Status: new to needs_review

Replying to lunar:

I have just attached a first working attempt of implementing NEWNYM through ControlSocket.

This is a very crude hack using js-ctypes but it is working nevertheless. It currently hardcode almost everything, but I'd like to have Mike's opinion before improving this very first attempt.

Woah.. Did you try to create a file-input-stream and file-output-stream xpcom component instead? Is there a reason you can't treat the filesystem socket as normal file io? Or perhaps pass the nsIFileInputStream to the binary-input-stream, like I did with the socket transport service socket in torbutton_send_ctrl_cmd()?

Looks like https://developer.mozilla.org/en/Code_snippets/File_I%2f%2fO has some examples. They all warn about doing sync file IO from the main thread, but ctypes is going to be just as bad, and more fragile.

Trac:
Cc: amnesia@boum.org to amnesia@boum.org, lunar

I have just noticed that 'inputStream' and 'outputStream' are not local variables in torbutton_send_ctrl_cmd(). Is that intended?

Replying to lunar:

I have just noticed that 'inputStream' and 'outputStream' are not local variables in torbutton_send_ctrl_cmd(). Is that intended?

Nope. Thanks. Fixed.

Unix domain sockets really are sockets. The file system handle is to be treated as an address and cannot be used as a usual file. So nsIFile{Input,Output}Stream will not work.

If I tried to look into Firefox's internals to see if there was a way to open a AF_UNIX socket, and it looks like the code is there in NSPR, but not there is no XPCOM interface. There is also no XPCOM interface that would receive an already open file descriptor, even if there is an underlying function that might be used in the netwerk library.

Pending you do not judge this hack as very wrong, I think I'd like to ship it (after some more refinements) in the Debian package, even if it might not be welcome in the standard Torbutton. Can you think of a reason not do to so?

Ugh. I thought we were dealing with named pipes here. Why did debian/tor settle on unix domain sockets instead of a named pipe on the filesystem?

Aside from that, the hack definitely needs to be hidden behind some debian-specific check that prevents the code from even entering the try block unless we're damn sure it is a debian system we're dealing with.

Named pipes that works both read/write are not well defined accross architectures. The default behaviour is also to have them block until the other end of the pipe is opened. IIRC, some systems implement non-blocking mode, but those are also quite architecture dependent.

"why did god make unix this way? :("

Anyways, I guess Tor uses sockets, not named pipes, so the discussion is probably irrelevant.

If you can wrap this codepath in a pref or other check so that it is only active on Debian and/or Iceweasel systems, I'll merge it. I just fear merging it on other platforms that may have a different libc location/name, etc. Or, perhaps just make it fail without a log notice in those cases?

Isn't the authentication cookie unnecessary here? You can control access to the ControlSocket simply by setting appropriate file permissions on the socket file (i.e. the user running firefox needs RW permissions to /var/run/tor/control). Surely that's the whole advantage of using unix domain sockets in the first place: you don't need an external authentication mechanism because you can rely on unix file permissions. Or am I missing something?

Mike looked at it (reviewed) and said, he'd accept the patch if there were changes. Subsequently the next state should be needs_revision.

Trac:
Cc: amnesia@boum.org, lunar to amnesia@boum.org, lunar, proper@secure-mail.biz
Status: needs_review to needs_revision

Trac:
Cc: amnesia@boum.org, lunar, proper@secure-mail.biz to anonym, intrigeri, lunar, proper@secure-mail.biz

Trac:
Cc: anonym, intrigeri, lunar, proper@secure-mail.biz to anonym, intrigeri, lunar, proper@secure-mail.biz, gk

Replying to lunar:

If I tried to look into Firefox's internals to see if there was a way to open a AF_UNIX socket, and it looks like the code is there in NSPR, but not there is no XPCOM interface.

FWIW that changed when https://bugzilla.mozilla.org/show_bug.cgi?id=892114 landed a while ago.

Trac:
Username: poncho
Cc: anonym, intrigeri, lunar, proper@secure-mail.biz, gk to anonym, intrigeri, lunar, proper@secure-mail.biz, gk, poncho@spahan.ch

Trac:
Keywords: N/A deleted, AffectTails added

Trac:
Keywords: AffectTails deleted, AffectsTails added

I think this bug can be resolved as a duplicate of #14271 (moved), which is closed. Does anyone disagree?

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal
Reviewer: N/A to N/A

Yes, it looks like a subset of #14271 (moved).

Trac:
Resolution: N/A to duplicate
Status: needs_revision to closed

closed

mentioned in issue #3968 (closed)

mentioned in issue #3994 (moved)

mentioned in issue #14270 (moved)

mentioned in issue #14271 (moved)