On Sun, 8 Apr 2018 11:55:08 -0400 "William L. Thomson Jr."
<wlt...@obsidian-studios.com> said:

> On Sun, 8 Apr 2018 13:52:26 +0900
> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> > On Sat, 7 Apr 2018 12:52:15 -0400 "William L. Thomson Jr."
> > <wlt...@obsidian-studios.com> said:
> > 
> > > On Fri, 6 Apr 2018 14:49:52 -0700
> > > Ross Vandegrift <r...@kallisti.us> wrote:
> > >   
> > > > Solution is to run WITH XDG_RUNTIME_DIR and HOME set to a temp
> > > > dir:
> > > > https://sources.debian.org/src/efl/1.20.7-4/debian/fake_home.sh/  
> > > 
> > > HOME was already reset, it was just  XDG_RUNTIME_DIR that was not
> > > reset Its is not a widely used variable. Thus Gentoo sandbox does
> > > not set by default like it does HOME and other stuff.
> > > 
> > > This was the simple answer I was looking for though I had already
> > > replied as such before this came across :)  
> > 
> > my very first answer explained why edje_cc does this then gave you an
> > answer - fix your sandbox.
> It was the wrong answer, and way more explanation than needed. The
> correct answer as stated by myself and other was to reset/override
> Nothing more need be stated, Short concise, reset/override that var. As
> my follow up email stated. 2 sentences...
> https://sourceforge.net/p/enlightenment/mailman/message/36286255/

mental note. never explain anything to you in future. :) you have no interest in
why. next time i shall just say:

"fix your sandbox to allow writing to that dir".

as that is the correct answer generically for any environment with an

> Explanation on edje_cc was not needed. Though I still stand by it
> should use an embedded connection to efreetd vs a daemon/socket. I can
> see why efreetd is a daemon for normal usage. Being a daemon for
> edje_cc usage does not make sense. Unless using an exising efreetd
> instance if already running. But starting one I think is bad. But that
> is all moot.
> >  you chose not to like the answer. it
> > would have happily fixed the violations because the access to this
> > dir is not an error or strange or unintended (which is why i
> > explained why it happens). bu unsetting the env var you are just
> > working around the problem, not fixing the root cause (the sandbox).
> I had the same issue in Travis with no sandbox. Thus your saying to fix
> sandbox was not correct. The sandbox was not broken. If anything not
> sanitizing all env variables, but that maybe intentional for other
> reasons.

i could explain why that is wrong... but see above. :)

> Not replacing or overriding a single variable hardly qualifies for
> sandbox being broken. A more accurate statement would be issues with
> build environment variables. Since that is the case for both sandbox
> and Travis environments.
> > imagine the day comes when XDG_RUNTIME_DIR is required and things
> > will hard fail without because apps don't want a "accessible by other
> > users" place for their sockets etc. and want it already secured. :)
> This was never about questioning that variable. The answer/solution
> involved that variable only.
> The reason sandbox does not touch that by default. Is due to not many
> applications using or relying on XDG_RUNTIME_DIR. That is just for
> desktop stuff, and the Unix/Linux software world is much larger than
> just desktop stuff. The vast majority of packages say in Gentoo would
> never use XDG_RUNTIME_DIR. So having sandbox scrub that is pointless.
> Plus even if I "fixed" sandbox. It would not address the issues in
> Travis. Which I ended up using /tmp as I had to many problems
> in Travis otherwise. Which again did not involve any sandbox.
> https://github.com/Obsidian-StudiosInc/entrance/commit/af884552f73006ed54b2dd09ceb429ba15d6252e
> -- 
> William L. Thomson Jr.

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