Re: Help testing full end-to-end xattr support in portage
"Anthony G. Basile" <[email protected]>
| Newsgroups | gmane.linux.gentoo.hardened |
|---|---|
| Message-ID | <[email protected]> |
On 07/02/14 09:41, Luis Ressel wrote: > On Sat, 28 Jun 2014 07:47:26 -0400 > "Anthony G. Basile" <[email protected]> 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 > Yep open a tracker bug for packages that invoke paxctl directly, and attach that to the main tracker bug, bug #427888. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197