Python executable needs PaX marking (preferably E with libffi) on Hardened. Ebuild takes care of marking the executable at the end of the compile phase. Somehow this marking is lost during install in case of python-3.5.1-r2. So it's there at the end of the compile phase, but it's not there in the image directory. Interestingly, python-3.4.3-r1 executable correctly keeps its marking during install phase. I haven't dig myself deeper into this problem: I'm not aware of any difference in between the two version of pythons' install. Reproducible: Always
laptop1 bin # paxctl-ng -v python3.4m python3.4m: XATTR_PAX : -E--- laptop1 bin # paxctl-ng -v python3.5m python3.5m: XATTR_PAX : not found laptop1 bin #
Skipping: EDRIVE_CANT_DO_THIS = EOPNOTSUPP Skipping: CDSL_NONE = (INT_MAX-1) Skipping: CDSL_CURRENT = INT_MAX * XATTR_PAX marking -E python with paxctl-ng >>> Source compiled. laptop1 / # cd /var/tmp/portage/dev-lang/python-3.5.1-r2/work/ laptop1 work # ls patches Python-3.5.1 x86_64-pc-linux-gnu laptop1 work # cd x86_64-pc-linux-gnu/ laptop1 x86_64-pc-linux-gnu # ls build Grammar libpython3.5m.so.1.0 Makefile Modules Programs python python-config.py config.log libpython3.5m.a libpython3.so Makefile.pre Objects pybuilddir.txt Python python-gdb.py config.status libpython3.5m.so Mac Misc Parser pyconfig.h python-config laptop1 x86_64-pc-linux-gnu # paxctl-ng -v python python: XATTR_PAX : -E--- laptop1 x86_64-pc-linux-gnu # ecompressdir: bzip2 -9 /usr/share/man ecompressdir: bzip2 -9 /usr/share/doc laptop1 / # cd var/tmp/portage/dev-lang/python-3.5.1-r2/image/usr/bin/ laptop1 bin # paxctl-ng -v python3.5m python3.5m: XATTR_PAX : not found laptop1 bin #
Created attachment 421818 [details] build log of python-3.5.1-r2
Okay here's what's going on here. Let's take 3.5.1-r2 as an example, but all the 3.5 have this problem. Line 1110 of Python-3.5.1/Makefile.pre.in reads as altbininstall: $(BUILDPYTHON) @FRAMEWORKPYTHONW@ @for i in $(BINDIR) $(LIBDIR); \ do \ if test ! -d $(DESTDIR)$$i; then \ echo "Creating directory $$i"; \ ... when expanded @FRAMEWORKPYTHONW@ becomes blank but altbininstall still depends on $(BUILDPYTON) which equals just "python". altbininstall is a dependency in the target for altinstall which is called during src_install() after the pax marking. for reasons i haven't yet figure out, make thinks "python" is out of date and rebuilds "python" thus clobbering the markings. this would happen with either ptpax or xtpax markings so its not an xattr issue. so this rule was in 3.4 as well, but there "python" doesn't go out of date and so the rebuild is not triggered during install. as a diagnostic, you can drop the dependency so line 1110 reads just as altbininstall: and sure enough, the markings are retained. but we really need to understand why $(BUILDPYTHON) goes out of date. a better fix is to insert `pax-mark.sh E $(BUILDPYTHON)" immediately after line 1110 but you have to be careful becaue you might alternatively need m and not E. i think we really need to understand why the rebuild is being triggered.
I'll try to look into this. In the mean time, we could just pax-mark the file in src_install as well.
(In reply to Mike Gilbert from comment #5) > I'll try to look into this. > > In the mean time, we could just pax-mark the file in src_install as well. okay to pax-mark the file in src_install
*** Bug 567350 has been marked as a duplicate of this bug. ***
*** Bug 563542 has been marked as a duplicate of this bug. ***
commit 0b8397ed5feba8c1ca964a75f740b364815496c4 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: Fri Jan 22 10:13:10 2016 -0500 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: Fri Jan 22 10:14:01 2016 -0500 dev-lang/python: pax-mark the python binary in src_install Bug: https://bugs.gentoo.org/569908 Package-Manager: portage-2.2.27_p47 dev-lang/python/python-3.5.1-r2.ebuild | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
I think this is occuring in all versions of python, at least the images I'm generating don't have the xattr pax marks
(In reply to Matthew Thode ( prometheanfire ) from comment #10) > I think this is occuring in all versions of python, at least the images I'm > generating don't have the xattr pax marks Do you also lose the PT pax marks?
(In reply to Matthew Thode ( prometheanfire ) from comment #10) > I think this is occuring in all versions of python, at least the images I'm > generating don't have the xattr pax marks That is not true for me -- in my installation python:2.7 has pax marks (see https://forums.gentoo.org/viewtopic-p-7861366.html).
it has the pt markings, so false alarm
3.5.2 is failing on PT_PAX system * PT_PAX marking -E python with paxctl * XATTR_PAX marking -E python with setfattr * Failed to set XATTR_PAX markings -E python. grsec: denied RWX mmap of <anonymous mapping> by /tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python paxctl -v /tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python PaX control v0.9 Copyright 2004,2005,2006,2007,2009,2010,2011,2012,2014 PaX Team <pageexec@freemail.hu> - PaX flags: -------xE--- [/tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python] RANDEXEC is disabled EMUTRAMP is enabled
(In reply to wbrana from comment #14) Please file a separate bug for that. It is probably a new issue.
(In reply to wbrana from comment #14) > 3.5.2 is failing on PT_PAX system > > * PT_PAX marking -E python with paxctl > * XATTR_PAX marking -E python with setfattr > * Failed to set XATTR_PAX markings -E python. > > grsec: denied RWX mmap of <anonymous mapping> by > /tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python > > paxctl -v /tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python > PaX control v0.9 > Copyright 2004,2005,2006,2007,2009,2010,2011,2012,2014 PaX Team > <pageexec@freemail.hu> > > - PaX flags: -------xE--- > [/tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python] > RANDEXEC is disabled > EMUTRAMP is enabled I experience issues caused by python binaries triggering PAX RWX mapping denials. Disabling mprotect workarounds the symptoms, while lowering security measures. Workaround: 1. let the emerge fail 2. paxctl-ng -m /var/tmp/portage/dev-lang/python-3.5.2/work/x86_64-pc-linux-gnu/python 3. ebuild /usr/portage/dev-lang/python/python-3.5.2.ebuild install 4. ebuild /usr/portage/dev-lang/python/python-3.5.2.ebuild qmerge I'm not sure if it is the new kernel, or some changes in userland causing these RWX-mapping newcommers. See related bug: https://bugs.gentoo.org/show_bug.cgi?id=589828
seem to be solved by now, possibly with upstream introduction of PGO builds
Mass closing of bugs reported against old versions of dev-lang/python. If the problem still occurs with the current versions (i.e. newest in each visible slot), feel free to reopen.
