Hello!
Just a short follow-up: I installed 319.49 as well, but the situation
is the same. A lot of applications give this error:
error while loading shared libraries: libGL.so.1: failed to map
segment from shared object: Operation not permitted
So no difference between 325.15 and 319.49 from this point of view.
I kept MPROTECT after all as you guys recommended, and I decided to use
revdep-pax. Unfortunately I encountered the following issue:
# revdep-pax -m -l /usr/lib/libGL.so
libGL.so.1 /usr/lib64/opengl/nvidia/lib/libGL.so.319.49 :X86_64 (-em--)
/usr/bin/cairo-sphinx ( -e--- )
/usr/bin/glxgears ( -e--- )
/usr/lib64/libcairo.so.2.11200.14 ( -e--- )
/usr/bin/vwebp ( -e--- )
/usr/lib64/libwebkitgtk-1.0.so.0.13.4 ( -e--- )
/usr/bin/glxinfo ( -e--- )
/usr/bin/xdriinfo ( -e--- )
/usr/lib64/libglut.so.3.9.0 ( -e--- )
/usr/lib64/libva-glx.so.1.3300.0 ( -e--- )
/usr/lib64/libGLU.so.1.3.1 ( -e--- )
/usr/lib64/va/drivers/vdpau_drv_video.so ( -e--- )
Will mark elf with -em--
Set flags for /usr/bin/cairo-sphinx (y/n): y
/usr/bin/cairo-sphinx ( ----- )
Set flags for /usr/bin/glxgears (y/n): y
/usr/bin/glxgears ( ----- )
The script actually *erased* the pax markings, instead of marking with
-em--:
# paxctl-ng -v /usr/bin/glxgears
/usr/bin/glxgears:
PT_PAX : -----
XATTR_PAX : -----
Do you have any ideas about this issue?
Notes: I use PT markings in kernel, and I have PAX_MARKINGS="PT" in
make.conf.
Thanks,
Balint
On Sat, 14 Sep 2013 15:33:56 +0300
Balint Szente <bal...@szentedwg.ro> wrote:
> [...]
> I understand and fully agree that CONFIG_PAX_MPROTECT is very
> important for security. However, I had to "-m" mark *a lot* of
> applications:
>
> Xorg, i3, i3bar, i3-nagbar and even "simple" GTK applications like
> claws-mail that has nothing with GLX (or maybe GTK has).
>
> I'm aware of the latest-stable ebuild issue with the pax-const.patch,
> but do you think it would make a difference from MPROTECT marking
> point of view? Is 319.49 behaving "more nicely" then 325.15?
