Concerning the "ephemerality" of it, I can imagine services being configured en passant by a cat >> socket from a shell script or so, [..]
On Tue, Feb 24, 2015 at 09:05:38PM +0400, meejah wrote:
You still need to authenticate. I do like the simplicity, but it will be a little more complex than that. I guess it's a bit of extra work to keep such a connection around. But really, it's just storing a PID and killing it when you're done.
posix has user/group access rights for file sockets and linux has acls on top of that. using a localhost socket is less secure, i agree.
It's still, I think, worth distinguishing somehow between an onion service added via SETCONF (which will get written to disc, and written to the torrc potentially) and the API Yawning has added that will vanish if the tor instance is re-started (and has no "hidden service dir" at all).
that is too inflexible.. i may want non-ephemeral services activated by a cat to a socket. i don't see the point in an artificial requirement to have config things frozen into a text file.
Another option could always be added in the future, like "lifetime={controller,tor}" or something if the "goes away with process" makes it harder than necessary to use. My instincts still say that "controller connection lifetime" is a good API, but that's not a super compelling argument ;)
the advantages of that aren't obvious to me. why would i need to make every networking app hold the hand of its router to let it know it's still needed? do we do this for regular networking, too? tor is on its way to becoming an AF_TOR - a networking esssential. making a hidden service could one day be as simple as doing listen() on an AF_TOR socket...