On 2013-12-20, Mike Gilbert <flop...@gentoo.org> wrote:
> On Fri, Dec 20, 2013 at 12:22 PM, Grant Edwards
><grant.b.edwa...@gmail.com> wrote:
>> On 2013-12-20, Grant Edwards <grant.b.edwa...@gmail.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!
