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,

Gustavo Sverzut Barbieri
Mobile: +55 (16) 99354-9890

enlightenment-devel mailing list

Reply via email to