[gentoo-user] Re: emerge: 'libsandbox.so' from LD_PRELOAD cannot be preloaded

[Grant Edwards]

On 2013-12-20, Mike Gilbert <floppym@g.o> wrote:
> On Fri, Dec 20, 2013 at 12:22 PM, Grant Edwards
><grant.b.edwards@×××××.com> wrote:
>> On 2013-12-20, Grant Edwards <grant.b.edwards@×××××.com> wrote:
>>> One of my systems has suddenly started displaying a lot of error
>>> messages any time any package is emerged:
>>>
>>> >>> Emerging (1 of 1) x11-terms/rxvt-unicode-9.18
>>>  * rxvt-unicode-9.18.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                               [ ok ]
>>>  ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
>>>  ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
>>> >>> Unpacking source...
>>> >>> Unpacking rxvt-unicode-9.18.tar.bz2 to /home/portage/tmp/portage/x11-terms/rxvt-unicode-9.18/work
>>> >>> Source unpacked in /home/portage/tmp/portage/x11-terms/rxvt-unicode-9.18/work
>>>  ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
>>>  ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
>>>  ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
>>>  ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
>>>  [...]
>>
>> This seems to have been caused by my setting the NET_RAW capability on
>> /usr/bin/python2.7.  I maintain several Python applications that have
>> to use raw sockets, and I got tired of having to use "sudo" to test
>> them -- I also thought it would be safer if I tested them with the
>> minimum capabilities required.  But, it appears that setting that
>> capability on the python executable (setting it on a .py file is
>> pointless) breaks the sandbox feature used by emerge.
>>
>> After removing the NET_RAW capability from /usr/bin/python2.7 the
>> sandbox errors went away.
>>
>> So now it's back to running my Python apps as root when all they
>> really need is raw sockets...
>
> An couple of workarounds for you:
>
> 1. Create a copy of the python2.7 binary, set the NET_RAW cap on that.

That's not a bad idea.

> 2. Create a small wrapper in C that calls the python2.7 binary. Set
>    the NET_RAW cap on the wrapper binary.

AFAICT, that won't work -- but I think something similar will.  The
NET_RAW capability will be lost when the wrapper binary does the
fork/exec.  But, I could set CAP_SETPCAP for the wrapper binary which
would then be able to fork/exec a child python process and set the
NET_RAW capability for that process.

Sure would be easier if network interfaces showed up under /dev so you
could use normal group permissions to deal with things like this...

-- 
Grant Edwards               grant.b.edwards        Yow! If I felt any more
                                  at               SOPHISTICATED I would DIE
                              gmail.com            of EMBARRASSMENT!