2013.Május 30.(Cs) 17:45 időpontban Magnus Granberg ezt írta: > torsdag 30 maj 2013 11.13.45 skrev Anthony G. Basile: >> >> migrate-pax also will copy PT_PAX to XATTR_PAX flags identically with >> one exception, if PT_PAX = "-e---" then no user.pax.flags xattr is >> created. I am always thinking in terms of either PAX_PT_PAX_FLAGS xor >> PAX_XATTR_PAX_FLAGS is on, not both. When both are on, we fall back on >> what you describe. So I adopted the approach: don't copy "-e---" to >> XATTR_PAX and when you reboot into a PAX_PT_PAX_FLAGS=n and >> PAX_XATTR_PAX_FLAGS=y kernel, you'll get the desired behavior. >> >> A good approach or no? > To use xattr pax flags PAX_MARKINGS need to be set to XT in make.conf > else will portage default to PT when marking. > Python need EMUTRAMP enable in the kernel with newer libffi and python > and have the E mark on the binary. > /Magnus > >
Thx for pointing that out. Note, that pax-utils eclass gentoo page describes the default action twice, differently: http://devmanual.gentoo.org/eclass-reference/pax-utils.eclass/index.html In the DESCRIPTION: "To control what markings are made, set PAX_MARKINGS in /etc/portage/make.conf to contain either "PT", "XT" or "none". The default is to attempt both PT_PAX and XATTR_PAX." In ECLASS VARIABLES: "Control which markings are made: PT = PT_PAX markings, XT = XATTR_PAX markings Default to PT markings." It would be good to make it unambiguous. I've appended PAX_MARKINGS="XT" to my make.conf, emerging python 3.2 dies in install phase with the following log snippet: --- Skipping: CDSL_CURRENT = INT_MAX * XT PaX marking -E with paxctl-ng * python >>> Source compiled. >>> Test phase [not enabled]: dev-lang/python-3.2.5 >>> Install python-3.2.5 into /var/tmp/portage/dev-lang/python-3.2.5/image/ category dev-lang make -j3 DESTDIR=/var/tmp/portage/dev-lang/python-3.2.5/image/ altinstall Creating directory /usr/bin /bin/sh: line 5: 24666 Killed LD_LIBRARY_PATH=/var/tmp/portage/dev-lang/python-3.2.5/work/x86_64-pc-linux-gnu: CC='x86_64-pc-linux-gnu-gcc -pthread' LDSHARED='x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -L. -Wl,-O1 -Wl,--as-needed -L.' CFLAGS=' -DNDEBUG -O2 -march=corei7-avx -pipe -fwrapv -O2 -march=corei7-avx -pipe -fwrapv ' ./python -E /var/tmp/portage/dev-lang/python-3.2.5/work/Python-3.2.5/setup.py $quiet build make: *** [sharedmods] Error 137 make: Creating directory /usr/include *** Waiting for unfinished jobs.... --- Let's check the marking on two python binaries. First the python binary the install tries to execute in the arch directory: paxctl-ng -v /var/tmp/portage/dev-lang/python-3.2.5/work/x86_64-pc-linux-gnu/python /var/tmp/portage/dev-lang/python-3.2.5/work/x86_64-pc-linux-gnu/python: PT_PAX : -e--- XATTR_PAX : -E--- If I try to manually execute the binary in the arch directory having XT emutramp enabled, it results in an instant kill. If I disable emutramp for both PT and XT, the binary executes fine. Next the python binary located in the image directory: axctl-ng -v /var/tmp/portage/dev-lang/python-3.2.5/image/usr/bin/python3.2 /var/tmp/portage/dev-lang/python-3.2.5/image/usr/bin/python3.2: PT_PAX : -e--- XATTR_PAX : not found If I try to manually execute the binary in the image directory, it shows normal behavior and display the python interpreter's prompt. My conclusions: On my systems XT markings make.conf entry causes troubles during the install phase while emerging python. The reason for the fail is that the binary gets killed instantly with EMUTRAMP on for XT. The binary in the image directory lack XT markings. I don't know if later it would get further markings, but it seems to me the markings are performed just before the install phase. So EMUTRAMP seems to harm python's normal execution and it's possible the necessary XT markings would not happen on the actual binary which will be qmerged to the system - as expected. I'm using the latest elfix from the hardened overlay, have this one specified in my repos.conf: --- [DEFAULT] # eclasses provided by hardened-dev takes precedence over # identically named eclasses that are provided by gentoo eclass-overrides = hardened-dev [gentoo] eclass-overrides = hardened-dev --- And I'm doing emerge --regen routinely after portage & layman syncs. I would be more than happy for doing some further testing or providing more info as needed. Regards: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
