On Jan 23, 2008 3:19 PM, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > On Jan 23, 2008 2:25 AM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > > > > * tcp to which host? > > The default, in my opinion, should be to use a regular Unix socket. If > you want a tcp socket, I think it's fair to require you to set it up > yourself, e.g. _you_ decide this by setting FISHD_SOCKET_DIR to e.g. > sparks.localdoman:1234 ... > With the above approach, none if this is an issue. Or at least, it is > someone elses problem, which is the same thing. ;-) ... > We can only launch a new fishd _if_ we are the specified host. If the > remote socket is dead for any reason, we're out of luck. > You essentially expect the user to maintain a network service. This is far from trivial, zero-configuration, highly reliable, or safe. With such weak promises, I doubt people will find it useful. I think it's only worth doing if it can be made to "just work". Magically "just working" is one of the cool things about uvars now.
> > * we should keep the unix socket for local connections, use tcp > > for remote access only. > > I doubt that the performance difference between using 10 tcp sockets > or using 9 tcp sockets and one unix socket is noticable. > Sure. I meant if from the reliability point of view - unix sockets always work. But "localhost" also always works, so I take that back. > * As Martin pointed out, the security implications are major. We > _definitely_ need authentication of some sort. By assuming a shared > home directory, one has effectively created what can be regarded as a > secure and authenticated sidechannel for this purpose, which is all > fine and useful, but I would definitely like to avoid writing my own > authantication mechanism if at all possible - that kind of code is > error prone. > The auth issue is very serious (controlling shell variables easily leads to executing arbitrary code). Stupid of me that I haven't considered it before proposing. I really believe that using the shared filesystem as the primary and only channel is better. * It's simple and easy to implement. * Making writes atomic is the only hard part. But it's doable. * It's as reliable and secure as the shared filesystem. * No configuration needed. Hosts come and go, the files stay there. If communicating through files is good enough remotely, it should be good enough locally. I want to implement it (hopefully this weekend) and see how well it works. Do you know anything that I missed which makes it a bad idea? Why is fishd needed? -- Beni Cherniavsky <[EMAIL PROTECTED]> (I read email only on weekends) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
