On Fri, 6 Apr 2018 11:28:58 -0400 "William L. Thomson Jr."
<wlt...@obsidian-studios.com> said:

> On Fri, 6 Apr 2018 14:10:51 +0900
> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> > On Thu, 5 Apr 2018 19:08:04 -0400 "William L. Thomson Jr."
> > <wlt...@obsidian-studios.com> said:
> > 
> > this is totally correct behavior for efreetd. efreetd is run when
> > efreet_init is called if the process can't connect to an existing
> > efreetd socket successfully. it's creating a dir for its socket so
> > that multiple processes can talk to it. it uses XDG_RUNTIME_DIR by
> > default if set, if not then it'll use /tmp instead for the socket
> > dir. this is not efreetd actually but ecore_con and it's policy of
> > pugging socket files if not a full path in RUNTIMEDIR/.ecore/
> Why does edje_cc need this? It seems to work with it failing. Which
> makes me think it is not necessary. If it was necessary, edje_cc would
> fail to generate the edj. 

edje (the lib) init efreet. it uses efreet to find cache directories.

> Why does edje_cc need to connect to an external efreetd process? Maybe
> it should use more embedded use of efreet and not rely on socket
> connection for a single process using efreet. Not running anything,
> building stuff.... No multiple process, no need for efreetd beyond
> edje_cc.
> > so - fix your sandbox to not disallow this. 
> Gentoo sandbox does not allow, nothing specific to my environment.

then gentoo's sandbox is broken. as i explained. the runtime dir is used for
sockets, tmp and other runtime files as libraries or processes need them (if
set). it's a standard that is well documented. as we re-use our libraries in
build tools they will inherit the same requirements.

> > limiting your sandbox from
> > accessing XDG_RUNTIME_DIR is probably a very bad idea, because this
> > is the standard "xdg" location for any run-time files. sockets or any
> > other relevant "only around during runtime of a users log in session"
> > files (thus they are not expected to persist and this dir and it not
> > shared between users etc.) :)
> This is during build, nothing is running. Also this violates
> Gentoo distro specific build policies.

of course something is running. edje_cc is running. for a short time, but it
is. the more complex the code becomes, the more it starts having sockets and
daemons etc. to share resources or multiplex access to a single resource etc.

> "All packages must build correctly when sandbox is active. "
> https://devmanual.gentoo.org/general-concepts/sandbox/

it's wrong then. :) xdg runtime dir is set and then access to it is denied.

> Very very few if any packages violate sandbox. Thus it is usually an
> application problem not sandbox. The only way I can get around is with
> FEATURES="usersandbox", which is incorrect hack around a problem.
> None the less this occurs even when not in a sandbox. This is running
> as root. Yet the directory creation is failing. It does not effect the
> application at all. Just like it had no effect on edje_cc.
> https://travis-ci.org/Obsidian-StudiosInc/entrance/jobs/362959773#L1203
> Completely different OS and environment, no sandbox, exact same error.
> Something seems off there. The direction creation fails a lot. It does
> not seem the failing ever has any effect on application run. If it was
> needed, application would fail or have some issue.
> Seems like something does need to be fixed.

yup. the sandbox env does. :) simple: access to xdg runtime dir is a necessity
for efl libs (if set as an env var - if the env var wasn't set we'd use /tmp
as a fallback... since your build env sets it... it's saying "use this place
for runtime sockets/data etc." but then it's going "well i told you to use that
dir... but no. i'll not allow it".

so... guess why i say the build env is broken? :) don;t set the env var
(XDG_RUNTIME_DIR), or allow access to where the env var points to to use for
runtime files. either way... the build env is broken. if we forced use of /tmp
instead then others would be right in saying "you don't respect xdg runtime dir
env vars". adding special efreet inits that bypass normal efreet init is just
working around a broken env adding complexity and more places for our code to
go wrong when clearly the build env is broken explicitly. the xdg runtime env
var is set. that means that dir is to be used for these purposes. its very
clear and explicit. disallowing access then is simply breaking the standard. so
allow access, or don't set the env var (and then efl falls back to /tmp for

------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
enlightenment-devel mailing list

Reply via email to