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 XDG_RUNTIME_DIR. 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/ 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. 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.
pgpLTmK6lTf03.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
