Re: [gentoo-dev] Re: sandbox access violations while running matlab binary installer

[Kfir Lavi]

On Mon, Mar 31, 2014 at 11:53 PM, Duncan <1i5t5.duncan@×××.net> wrote:

> Alexandre Rostovtsev posted on Mon, 31 Mar 2014 14:54:09 -0400 as
> excerpted:
>
> > The best solution is to figure out why the directory is being created
> > there and whether it is customizable. Maybe the code actually is
> > creating $HOME/InstallShield? Then export HOME=${T} in your ebuild.
>
> Well, "best" would be not to run software where the author doesn't
> respect your rights to study, patch and share the software, with or
> without those modifications, in the first place.
>
> But understanding not everybody is prepared to go that route and it's
> their machines and life, not mine...
>
> On the ebuild execution side, as a last resort you can turn off
> FEATURES=sandbox and perhaps FEATURES=userpriv as well, allowing it free
> access to do whatever it's going to do.
>
> Alternatively and for both the ebuild creation and execution sides, take
> a look at /etc/sandbox.conf and the files in /etc/sandbox.d/, and grep
> SANDBOX_ in $PORTDIR/*/*/*.ebuild and $PORTDIR/eclass/*.eclass.
>
> (Tho it's not always proprietaryware; take a look at emacs... based on
> some of the other packages that disable sandbox, I'd guess it's the lisp.)
>
> Anyway, SANDBOX_PREDICT or SANDBOX_WRITE will probably do it in your case
> (violations not flat-out-segfaults as emacs apparently triggers), but
> SANDBOX_ON=0 is there if you REALLY need it.
>
> Tho obviously if you were doing that ebuild for the main tree, any
> messing with sandbox isn't going to get it there any faster.  But if
> you're doing it for your own (including possibly company internal) use
> only...
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>
Thanks Duncan,

addwrite /root/InstallShield
addwrite /etc/mtab

did the trick.

Thanks all for replaying.

Kfir