On Wed, Sep 21, 2016 at 8:13 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Wed, 21 Sep 2016 11:29:00 -0300 Gustavo Sverzut Barbieri
> <barbi...@gmail.com> said:
>
>> 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?
>
> or ... never die. ever. once up, stay up (of course until session shuts down).
> unless of course it's a crash/bug/segv in which case there is no unlink. :)

we never crash :-D

seriously, this is not possible.


>> >> 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...
>
> efreetd doesnt need such caps. neither does this efl.proxy. remember how i
> differentiated between "global resources" vs things like thumbnails where
> thumbs are not global resources - they are directly tied tot he src file and
> permissions on it and the permissions of the app etc.
>
> a "proxy lookup" daemon is going to provide a global resource - the ability to
> take an input target machine and give a resulting proxy server to use, and 
> that
> global resource may be as simple as an $http_proxy env var, or as complex as a
> bunch of js in a pac file to execute to figure out which proxy to use.

that's the case, you may need to talk to some configuration daemon
(ie: gsettings) or even the network (ie: http://wpad/wpad.dat or
http://wpad.${searchdomain}/wpad.dat) and then you may be limited by
some inherited capability.

then you're right the daemon and its output is global, however it may
be launched from a specific scope and thus not delivering what it
should.



>> say constrained process A spawned the daemon. Then unconstrained
>> process B will get the constraints.
>
> in a constrained environment like one with SMACK this daemon would launch as
> part of your login session. such constrained environments have to deal with
> this. they could also set up systemd socket activation too. efreetd - same
> story. outside of such env's the "i'll launch if i can't connect" just works
> (tm).

this is what I suggest, to launch it elsewhere. I mentioned systemd,
you also mention systemd here... but then, right below you bash that
option :-/ note that is only an example of a possibility, it's not
mandated.


>> 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.
>
> actually it'd still work because proxy daemon is doing a lookup locally as to
> what to use. the app itself still does the connect and thus gets blocked. the
> proxy daemon isnt meant to be doing dns lookups or anything else - just return
> the $http_proxy to use or runt he js to figure out what proxy to use given a
> nice fat bit of data in the pac file to choose what may be internal and/or
> external sites by name/ip etc. and what proxy to use.

no, that may be accessing an URL in the case user choose PAC (Proxy
Auto Configuration), which is recommended in most setups.

it will then need HTTP and DNS access.

some configuration input, like for official libproxy, will need
gsettings access. Others will need dbus (ie: pacrunner). If we go
crazy and reimplement that ourselves in EFL, we still need file access
-- as you know that comes with constraints.


>> 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.
>
> such constrained environments have to launch the proxy daemon separately. as
> above. as long as they either set up socket activation OR just launch it on
> login everything works as normal.

ok, this is what I proposed... sounds reasonable.


>> 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.
>
> and everyone on bsd, windows, osx will hate you for doing this. tying to
> systemd as the ONLY and DEFAULT method is stupid. you shot portability in the
> foot.

Did you read what I wrote? It's exactly what you propose above in your
reply... so I guess you didn't read or I wrote an awful explanation.

The systemd case is where an external entity spawns the proxy daemon.
Preferably via socket activation, so the application will never fail,
just block waiting, thus will never try to launch a daemon itself.


> the PORTABLE way that works on osx, windows (assuming local sockets work),
> bsd's, solaris, linux and EVERY *nix is what i described. connect, if connect
> fails, launch, then keep connecting until success.

There are issues with this approach, so it's not as portable as you think.

Nonetheless I'm not saying we're not going to support what you
propose, as I wrote right after this paragraph.


> "odd" constrained env's can simply avoid ever needing to trigger the "launch"
> code by ensuring the daemon is already started OR use socket activation.
> ecore_con/ipc already supported socket activation systemd stuff if the systemd
> env vars were set to pass in the socket fd. all of that is/was already done...
> ship/add the systemd socket file then too as part of a user session.

gosh, this is what I said... :-/ read the next paragraph.


> but FIRST do the "i'll launch it myself" code as that is universal. one code
> path for everyone everywhere on every os.

this is what I said, read the next paragraph.

the systemd part it solely on the daemon code, client doesn't need to
be aware of that. The only thing the daemon must do is check if an fd
was given to it OR if it must create the fd itself...


> those with systemd ANd that have systemd managing their login session can then
> rely on tyhe socket activation. catch - the socket file has to be installed 
> int
> he right place. currently wee have a mess that we install such files where
> systemd say to and not in $PREFIX which is pretty bad as it's unexpected
> out-of-target dir file installs. but if we dont then systemd isnt looking
> in /usr/local/.... by default. that's all a mess and we had this mess for 
> years
> with dbus activation files. still do with ethumb. enough. this cant be the
> default/only way. it needs to be an optional extra.

This is because the file is not for E to use, then it makes no sense
to put it where E was installed or is looking at. They must be placed
where systemd or dbus are.

However one can set some envvars to force systemd/dbus to look at
those. But as the daemon may be running already, you may not be able
to tell it to immediately look where you want, would need to set the
envvars and restart system/session.


> those on constrained environments can use the above socket activation OR ...
> just ensure these daemons are launched to avoid problems. same story as socket
> activation. they do have a constrained env and they have to do some work to
> take care of things in such an env.
>
> and for the rest things just work™. thats the important bit. that they just
> work out of the box.
>
>> 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.

this is the paragraph I was mentioning above. I wrote exactly you were
asking for.


>> looks good?
>
> no. no idle die. see above. :) it's portable. it's simple. it works everywhere
> until you have oddball smack/selinux etc. envs and then the env can take care
> of it via launch or socket actvation. first make the "works everywhere"
> version. :)

it's almost done, the libproxy.so needs to fork-exec on errors... that's it.


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

Reply via email to