Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage

[Luis Ressel]

On Sat, 28 Jun 2014 07:47:26 -0400
"Anthony G. Basile" <basile@××××××××××××××.edu> wrote:

> There are two advantages to paxctl over paxctl-ng from elfix: 1) It
> doesn't depend on elfutils to do its manipulation of elf phdr's.  2)
> It does try to convert or create a PT_PAX_FLAGS phdr by either
> creating (-C) or converting (-c) a PT_GNU_STACK phdr.
>
> The advantage of paxctl-ng over paxctl is 1) it is designed to do
> both PT_PAX and/or XATTR_PAX markings, 2) it is consciously designed
> to not try to create/convert ELF phdr's.
>
> If we ever drop the PT_PAX_FLAGS patch from binutils then paxctl
> would no longer be needed and paxctl-ng can be reduced to just doing
> XATTR_PAX markings.
>
> One step at a time ;)

Okay, that sounds reasonable. And as paxctl is a small program, it
doesn't hurt to have it around on XATTR_PAX-only systems even though
it's not needed.

But there's still an issue. According to [1], 15 packages still depend
on or invoke paxctl directly. One example is dev-lisp/sbcl, which needs
pax markings at one point right in the middle of the build process and
therefore can't use the pax eclass, at least not in a simple way. This
doesn't work on systems like mine which don't respect PT_PAX flags.

I'm currently working on a patch for sbcl (there are selinux-related
issues as well), but please have a look at the other ebuilds.

[1] $ echo /usr/portage/*/*/*.ebuild|xargs -n1000 grep -P 'paxctl(?!-ng)'|cut -d: -f1


Regards,
Luis Ressel