On Wed, Sep 21, 2016 at 9:08 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 20 Sep 2016 19:12:57 -0300 Gustavo Sverzut Barbieri > <barbi...@gmail.com> said: > >> damn raster... I had to do so I could check. >> >> dlopen -> in git. >> >> server and libproxy.so wrapper, attached with the basics, I'm not >> doing all the cumbersome details to get a single process running and >> spawn it from libproxy.so wrapper without a race condition. > > there is no race. > > connect. if connect fail, spawn, set timer to connect every 0.1 sec until > successful. > > there is no race. first daemon spawned that binds to the socket wins. every > other one will fail and exit. there is no race to deal with as the bind does > the job for the daemon - first one in wins and the rest fail.
there is a problem with stale sockets. If daemon dies and leaves the socket file, then next daemons will try to bind and fail... then nobody wins. If we first unlink(), then there is a race. Or should we use an abstract socket? >> I'd simplify all of that by using dbus with acquiring a name in the >> session bus and let that entity control it. Also would let the dbus >> daemon set isolation, like not inheriting current processes limits, >> namespaces and all. > > no it isn't any easier with dbus. see above. this is what efreetd does not. > its > REALLyYsimple and race-free. still doesn't address inheriting caps and other access controls... say constrained process A spawned the daemon. Then unconstrained process B will get the constraints. more concrete description is: for some reason "A" was started without network access. The daemon inherits that and thus libproxy won't work. That's okay, expected. However "B" has network access and is started afterwards, it will check and the daemon is there. It will use the daemon with libproxy that doesn't work due lack of network access. This is not expected. I know not all systems employ fine grained capabilities and smack/selinux, but some do and we need to be careful. What I can do to solve this is to allow the server to be started from socket activation like systemd (also in --user variant). In that case, if the user cares about isolation, he uses the efl-proxy-resolver.socket and efl-proxy-resolver.service to start those on demand. The client will try to connect and it will work, thus it won't spawn any daemon on its own. Systemd will spawn the service with proper caps. If systemd is not used, then the client will fail to connect, will fork-exec the daemon and it will create and bind the socket on its own, inheriting parent's caps. A possible workaround for this is to die after some idle timeout, then it would "auto-fix" if problems like that happens. looks good? >> however as you dislike that, be my guest :-D >> >> gcc -o efl-proxy-resolver libproxy-efl-server.c `pkg-config --cflags >> --libs ecore eina efl eo libproxy-1.0` >> gcc -shared -o libproxy-efl.so libproxy-efl.c `pkg-config --cflags >> eina` -lpthread > > why did you do both a client exe and a server? just need the server... the > client copnnect/talk is in efl.net :) if you use efl.net like ecore_con it'd > do > the XDG_RUNTIME_DIR for you for user local sockets (unless they are full > path). > yuou just should have re-use efl.net inside there. client is not an exe, it's a libproxy.so drop-in replacement so you can LD_PRELOAD, like from E... after all you want all your processes to use the same proxy configuration and benefits, right? VLC, glib, qt... -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
