I've applied the patch. I have USE=xattr enabled, the kernel has both CONFIG_PAX_XATTR_PAX_FLAGS=y and CONFIG_PAX_PT_PAX_FLAGS=y set, and elfix was emerged with USE="ptpax xtpax" combo (since I'm not brave enough). The only exception from the instructions is that I have PAX_MARKINGS="PT XT" specified in make.conf.
Taken this difference, I've emerged some packages. The install process is faster - although I wouldn't say it's lightning fast. All binaries had their PT fields set and XT fields missing. I can only blame the PAX_MARKINGS variable. I believe that the install mechanism should take care both PT and XT flags if both were specified in PAX_MARKINGS environmental variable. I'm not sure if you agree with me about this. I can repeat the test it with PAX_MARKINGS="XT" only. Thank you for your efforts: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057 2014.Június 24.(K) 15:53 időpontban Anthony G. Basile ezt írta: > Hi Everyone, > > It has take a long time to finalize XATTR_PAX support in Gentoo, but I > think the final step is done. The thorniest problem was getting portage > wrappers to `/usr/bin/install` to preserve extended attributes. We > could have hacked up ebuilds to do the markings after install, but in > some cases this meant having to do double markings in ebuilds and left a > gap in our end-to-end support for other packages needing xattrs not > necessarily related to PaX. I took the harder but "correct" path and > wrote a wrapper. My first wrapper was written in python and worked > great except it was slooooow --- actually I had one in bash which used > associated arrays but that requires bash4 and portage only supports > bash3! I rewrote the wrapper in C and it worked great when I by-passed > the portage install machinary and used it directly, but the point was to > get it working in portage! I finally traced the bug down to how the > environment $PATH changes during the ebuild phases and added > intelligence to the C wrapper. > > Anyhow, I'd like victims ... err ... I mean testers: > > 1) Have USE=xattr and PAX_MARKINGS="XT" in you make.conf file > > 2) Your kernel should have CONFIG_PAX_XATTR_PAX_FLAGS=y. If you are > brave have CONFIG_PAX_PT_PAX_FLAGS not set. > > 3) emerge =sys-apps/install-xattr-0.2, sys-apps/elfix. If you can > emerge elfix with USE="ptpax xtpax" but if you are brave try USE="-ptpax > xtpax". You must have at least xtpax in there. > > 4) You need to apply the following patch to portage: > > https://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9089c2d755b0ecb1b340fc23dda461163f589c43 > > You can just manually apply it after `cd /usr/lib/portage/` > > 5) Then emerge any package needing pax markings (maybe not python just > in case something breaks). Like johntheripper which should give > > ~ # paxctl-ng -v /usr/sbin/john > /usr/sbin/john: > PT_PAX : -emr- > XATTR_PAX : -emr- > > or just > > /usr/sbin/john: > XATTR_PAX : -emr- > > If you removed all PT_PAX above. > > Let me know if you hit issues. The final step will be to just make sure > our releases have XATTR_PAX markings and that we document how to > properly installed them so you don't loose the markings. > > > Finally, some may wonder, why XATTR_PAX markings? The main reason is > that it doesn't touch the ELF binaries and makes them more consistent > with what other distros ship. Also, marking can be done while the ELF > is busy (eg `paxctl -m /bin/bash`, leads to "Text file busy" but you > can always do `paxctl-ng -lm /bin/bash`, ie set only XATTR_PAX). This > allows you to work with a live system which is useful if you ever need > to do a revdep-pax to migrate pax flags from a library to the > executables that link against it. The disadvantage is that xattr > support requires more work and so are more fragile. > > > -- > Anthony G. Basile, Ph. D. > Chair of Information Technology > D'Youville College > Buffalo, NY 14201 > (716) 829-8197 >
