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

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

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.

William L. Thomson Jr.

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

Reply via email to