From: "Anthony G. Basile" <basile@opensource.dyc.edu>
To: gentoo-hardened@lists.gentoo.org
Subject: Re: [gentoo-hardened] Help testing full end-to-end xattr support in portage
Date: Thu, 03 Jul 2014 06:48:42 -0400 [thread overview]
Message-ID: <53B5350A.4050700@opensource.dyc.edu> (raw)
In-Reply-To: <53B533C0.7070502@opensource.dyc.edu>
On 07/03/14 06:43, Anthony G. Basile wrote:
> On 07/02/14 09:41, Luis Ressel wrote:
>> On Sat, 28 Jun 2014 07:47:26 -0400
>> "Anthony G. Basile" <basile@opensource.dyc.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
>>
>
> Yep open a tracker bug for packages that invoke paxctl directly, and
> attach that to the main tracker bug, bug #427888.
>
Actually I'll do it.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
next prev parent reply other threads:[~2014-07-03 10:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 13:53 [gentoo-hardened] Help testing full end-to-end xattr support in portage Anthony G. Basile
2014-06-24 17:25 ` Alex Efros
2014-06-26 12:57 ` Anthony G. Basile
2014-06-26 15:19 ` Alex Efros
2014-08-05 2:48 ` Alex Efros
2014-08-06 9:21 ` Jason Zaman
2014-08-06 9:45 ` Alex Efros
2014-06-26 16:26 ` "Tóth Attila"
2014-06-26 22:17 ` Luis Ressel
2014-06-28 11:47 ` Anthony G. Basile
2014-07-02 13:41 ` Luis Ressel
2014-07-03 10:43 ` Anthony G. Basile
2014-07-03 10:48 ` Anthony G. Basile [this message]
2014-07-03 11:20 ` Anthony G. Basile
2014-07-12 20:28 ` Luis Ressel
2014-07-13 9:51 ` Luis Ressel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B5350A.4050700@opensource.dyc.edu \
--to=basile@opensource.dyc.edu \
--cc=gentoo-hardened@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox