Re: Help testing full end-to-end xattr support in portage

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
>