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

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

[Samuli Suominen]

On 31/03/14 21:15, Kfir Lavi wrote:
> Hi all,
> I'm trying to create an ebuild to install matlab MCR on gentoo.
> The installer InstallShileld try to create directory
> /root/InstallShield ;-)
> mkdir is run by java binary that try this. So I have no access to
> change it.
> There is no option to provide InstallShield it's relative install path.
> I can provide matlab's install path and other options, but this made
> permanent /root/InstallShield
>
> What can I do?
>
> Thanks,
> Kfir

Try the gentoo-user mailing list or forums.   Nothing we can do from
Gentoo's side, ie. wrong mailing list.

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

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Hi all,
I'm trying to create an ebuild to install matlab MCR on gentoo.
The installer InstallShileld try to create directory /root/InstallShield ;-)
mkdir is run by java binary that try this. So I have no access to change it.
There is no option to provide InstallShield it's relative install path.
I can provide matlab's install path and other options, but this made
permanent /root/InstallShield

What can I do?

Thanks,
Kfir

[-- Attachment #2: Type: text/html, Size: 592 bytes --]

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

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Mon, Mar 31, 2014 at 9:14 PM, Samuli Suominen <ssuominen@gentoo.org>wrote:

>
> On 31/03/14 21:15, Kfir Lavi wrote:
> > Hi all,
> > I'm trying to create an ebuild to install matlab MCR on gentoo.
> > The installer InstallShileld try to create directory
> > /root/InstallShield ;-)
> > mkdir is run by java binary that try this. So I have no access to
> > change it.
> > There is no option to provide InstallShield it's relative install path.
> > I can provide matlab's install path and other options, but this made
> > permanent /root/InstallShield
> >
> > What can I do?
> >
> > Thanks,
> > Kfir
>
> Try the gentoo-user mailing list or forums.   Nothing we can do from
> Gentoo's side, ie. wrong mailing list.
>
> Is there a way to contain this violation and provide a pseudo permissions
to use /root/InstallShield

[-- Attachment #2: Type: text/html, Size: 1305 bytes --]

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

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.

On March 31, 2014 2:24:24 PM EDT, Kfir Lavi <lavi.kfir@gmail.com> wrote:
>On Mon, Mar 31, 2014 at 9:14 PM, Samuli Suominen
><ssuominen@gentoo.org>wrote:
>
>>
>> On 31/03/14 21:15, Kfir Lavi wrote:
>> > Hi all,
>> > I'm trying to create an ebuild to install matlab MCR on gentoo.
>> > The installer InstallShileld try to create directory
>> > /root/InstallShield ;-)
>> > mkdir is run by java binary that try this. So I have no access to
>> > change it.
>> > There is no option to provide InstallShield it's relative install
>path.
>> > I can provide matlab's install path and other options, but this
>made
>> > permanent /root/InstallShield
>> >
>> > What can I do?
>> >
>> > Thanks,
>> > Kfir
>>
>> Try the gentoo-user mailing list or forums.   Nothing we can do from
>> Gentoo's side, ie. wrong mailing list.
>>
>> Is there a way to contain this violation and provide a pseudo
>permissions
>to use /root/InstallShield

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

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

[Mike Gilbert]

On Mon, Mar 31, 2014 at 2:54 PM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:
> 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.
>

Portage already sets HOME to a subdirectory of ${PORTAGE_TMPDIR).
Setting it to ${T} will make no difference there.

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

[Samuli Suominen]

On 31/03/14 21:24, Kfir Lavi wrote:
>
>
>
> On Mon, Mar 31, 2014 at 9:14 PM, Samuli Suominen <ssuominen@gentoo.org
> <mailto:ssuominen@gentoo.org>> wrote:
>
>
>     On 31/03/14 21:15, Kfir Lavi wrote:
>     > Hi all,
>     > I'm trying to create an ebuild to install matlab MCR on gentoo.
>     > The installer InstallShileld try to create directory
>     > /root/InstallShield ;-)
>     > mkdir is run by java binary that try this. So I have no access to
>     > change it.
>     > There is no option to provide InstallShield it's relative
>     install path.
>     > I can provide matlab's install path and other options, but this made
>     > permanent /root/InstallShield
>     >
>     > What can I do?
>     >
>     > Thanks,
>     > Kfir
>
>     Try the gentoo-user mailing list or forums.   Nothing we can do from
>     Gentoo's side, ie. wrong mailing list.
>
> Is there a way to contain this violation and provide a pseudo
> permissions to use /root/InstallShield

Have you looked into using `addpredict` or `addwrite`?

For examples, check,

# cd /usr/portage
# grep addpredict */*/*.ebuild

And same for addwrite.

(And I still believe this discussion should be in the gentoo-user ML,
but since others have replied too, might as well.)

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

[Duncan]

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

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

[Michael Orlitzky]

On 03/31/2014 02:14 PM, Samuli Suominen wrote:
> 
> On 31/03/14 21:15, Kfir Lavi wrote:
>> Hi all,
>> I'm trying to create an ebuild to install matlab MCR on gentoo.
>> The installer InstallShileld try to create directory
>> /root/InstallShield ;-)
>> mkdir is run by java binary that try this. So I have no access to
>> change it.
>> There is no option to provide InstallShield it's relative install path.
>> I can provide matlab's install path and other options, but this made
>> permanent /root/InstallShield
>>
>> What can I do?
>>
>> Thanks,
>> Kfir
> 
> Try the gentoo-user mailing list or forums.   Nothing we can do from
> Gentoo's side, ie. wrong mailing list.
> 

I'd point out gentoo-devhelp@gentoo.org as well. It's quiet, but that's
a good thing.

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

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

On Mon, Mar 31, 2014 at 11:53 PM, Duncan <1i5t5.duncan@cox.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

[-- Attachment #2: Type: text/html, Size: 2739 bytes --]

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

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/01/2014 10:03 AM, Kfir Lavi wrote:
> On Mon, Mar 31, 2014 at 11:53 PM, Duncan <1i5t5.duncan@cox.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
> 

IIRC, you really should use `addpredict` instead of `addwrite`, as you don't want the package
*really* writing to those locations.

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTO3zXAAoJELHSF2kinlg4emwQAJNwluWdrGXrBMj3f+j4Sx8+
Ch6M5FF5lRqQXnnqZUvXrEd2t6iBMrZ0Xm/AVnAkCNr4vlpRdcS7ahmbCSC4jT2f
Plct5CG6+3/W1PbNfmSLoBxIlEU8vMzx4gUJtaGUOuuekjuYK+xKHjlskVJks0Y8
im0k/1VDR13J6NyneBmISH0SglmYmVTAezT9yngqm089cfi4DkZo4MdR/r4TUtRd
lu62NlZ517t2pNINJe5anRq9Q0D+obGg8gmZ0+C2jNwj+9thXZWnSLuV03eXpIG3
ntVaVRI2H4p9hPWQJMCfVsyVfudYDiP/05hOkeTOd3NV+8crODoY06CQNhZ7e0hb
yB+TE+bqufAuqaEalhEB5oxn61u+ALYHCXSRNjuQItzZrWRSXqV6r7Hd9TKtHEL0
w+ayThJYXqWDSj69yXpyHMldWovydKMVv7Goz9gdzBjPIRVfLZoUmvpl1RGwsOII
ahubgQPp2n0cibm0K2Uaqr1xg7MuvUr810hl/LVhK8OlsT3gqDgMXyZrG6S1x/jo
DV7qCJCqy5GjDc4KdS/tPTXJt9krAjRNDIxfA/jzvOC8lghZuAFFZpUSHfBR9XL+
VUMUwhwdathtQic20+t4vnXP24AetYvqaO7K1dRFJhopGE8P0gnt7r8xQa5uZSkr
QtKhDStXVcLkOnuw3jy+
=3dEf
-----END PGP SIGNATURE-----

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

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]

On Wed, Apr 2, 2014 at 5:58 AM, Jonathan Callen <jcallen@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 04/01/2014 10:03 AM, Kfir Lavi wrote:
> > On Mon, Mar 31, 2014 at 11:53 PM, Duncan <1i5t5.duncan@cox.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
> >
>
> IIRC, you really should use `addpredict` instead of `addwrite`, as you
> don't want the package
> *really* writing to those locations.
>

I have tried it, but the installation does not work.
Matlab does not really install itself, as it throws a lot of
NullPointerException.
What I'm doing is letting it write using addwrite and then at the post
install I delete this directory.

What I don't understand is, why it needs to get write permissions to
/etc/mtab ?


> - --
> Jonathan Callen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCgAGBQJTO3zXAAoJELHSF2kinlg4emwQAJNwluWdrGXrBMj3f+j4Sx8+
> Ch6M5FF5lRqQXnnqZUvXrEd2t6iBMrZ0Xm/AVnAkCNr4vlpRdcS7ahmbCSC4jT2f
> Plct5CG6+3/W1PbNfmSLoBxIlEU8vMzx4gUJtaGUOuuekjuYK+xKHjlskVJks0Y8
> im0k/1VDR13J6NyneBmISH0SglmYmVTAezT9yngqm089cfi4DkZo4MdR/r4TUtRd
> lu62NlZ517t2pNINJe5anRq9Q0D+obGg8gmZ0+C2jNwj+9thXZWnSLuV03eXpIG3
> ntVaVRI2H4p9hPWQJMCfVsyVfudYDiP/05hOkeTOd3NV+8crODoY06CQNhZ7e0hb
> yB+TE+bqufAuqaEalhEB5oxn61u+ALYHCXSRNjuQItzZrWRSXqV6r7Hd9TKtHEL0
> w+ayThJYXqWDSj69yXpyHMldWovydKMVv7Goz9gdzBjPIRVfLZoUmvpl1RGwsOII
> ahubgQPp2n0cibm0K2Uaqr1xg7MuvUr810hl/LVhK8OlsT3gqDgMXyZrG6S1x/jo
> DV7qCJCqy5GjDc4KdS/tPTXJt9krAjRNDIxfA/jzvOC8lghZuAFFZpUSHfBR9XL+
> VUMUwhwdathtQic20+t4vnXP24AetYvqaO7K1dRFJhopGE8P0gnt7r8xQa5uZSkr
> QtKhDStXVcLkOnuw3jy+
> =3dEf
> -----END PGP SIGNATURE-----
>
>

[-- Attachment #2: Type: text/html, Size: 4900 bytes --]

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

[Duncan]

Kfir Lavi posted on Wed, 02 Apr 2014 13:38:47 +0300 as excerpted:

> What I don't understand is, why it needs to get write permissions to
> /etc/mtab ?

That is a worrisome indeed, since /etc/mtab is now often a symlink to 
/proc/self/mounts (or to /proc/mounts which in symlinks to /proc/self/
mounts), which is kernel-enforced read-only.

Either way, attempts to write to the symlink target (/proc/self/mounts) 
*OR* to replace the symlink are worrisome, tho attempts to write the 
target only potentially disrupt the writer, while successfully replacing 
the symlink could leave a system and thus its sysadmin in a world of hurt.

Yet another lesson on the evils of proprietary/servantware code and the 
violation of the freedom of actual users to properly see what's going on 
and to fix it. <shrug>

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

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

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Apr 3, 2014 5:59 PM, "Duncan" <1i5t5.duncan@cox.net> wrote:
>
> Kfir Lavi posted on Wed, 02 Apr 2014 13:38:47 +0300 as excerpted:
>
> > What I don't understand is, why it needs to get write permissions to
> > /etc/mtab ?
>
> That is a worrisome indeed, since /etc/mtab is now often a symlink to
> /proc/self/mounts (or to /proc/mounts which in symlinks to /proc/self/
> mounts), which is kernel-enforced read-only.
>
> Either way, attempts to write to the symlink target (/proc/self/mounts)
> *OR* to replace the symlink are worrisome, tho attempts to write the
> target only potentially disrupt the writer, while successfully replacing
> the symlink could leave a system and thus its sysadmin in a world of hurt.
>
> Yet another lesson on the evils of proprietary/servantware code and the
> violation of the freedom of actual users to properly see what's going on
> and to fix it. <shrug>
>
> --
> 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
>
>
I think the developer of install shield just open it for reading with a
read write call.
I'm with you on every word you wrote.

[-- Attachment #2: Type: text/html, Size: 1527 bytes --]