[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[carlo von lynX]

> > 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...