Mailing List Archive

Hi!

On Mon, Sep 09, 2013 at 09:30:56AM -0400, Michael Orlitzky wrote:
> That is, can I disable PT_PAX, enable XATTR_PAX, reboot, and run
> migrate-pax? Or might that cause problems?

You can migrate with just one reboot, but order of actions is different:

1. Build new kernel with PT_PAX disabled and XATTR_PAX enabled.
2. Run `migrate-pax -m`.
3. Reboot using new kernel.

I'm not really sure, but you may also need to add PAX_MARKINGS="XT" into
/etc/make.conf.

--
WBR, Alex.

On 09/09/2013 09:49 AM, Alex Efros wrote:
> Hi!
>
> On Mon, Sep 09, 2013 at 09:30:56AM -0400, Michael Orlitzky wrote:
>> That is, can I disable PT_PAX, enable XATTR_PAX, reboot, and run
>> migrate-pax? Or might that cause problems?
>
> You can migrate with just one reboot, but order of actions is different:
>
> 1. Build new kernel with PT_PAX disabled and XATTR_PAX enabled.
> 2. Run `migrate-pax -m`.
> 3. Reboot using new kernel.

Thanks, I'll give it a try (on the router in the building where I have
keys, first...).


> I'm not really sure, but you may also need to add PAX_MARKINGS="XT" into
> /etc/make.conf.
>

pax-utils.eclass has this to say:

To control what markings are made, set PAX_MARKINGS in /etc/portage
/make.conf to contain either "PT", "XT" or "none". The default is to
attempt both PT_PAX and XATTR_PAX.

But then again, right below that, I see,

# @ECLASS-VARIABLE: PAX_MARKINGS
# @DESCRIPTION:
# Control which markings are made:
# PT = PT_PAX markings, XT = XATTR_PAX markings
# Default to PT markings.
PAX_MARKINGS=${PAX_MARKINGS:="PT"}

So I'm not really sure either.

On 09/09/2013 10:19 AM, Michael Orlitzky wrote:
> On 09/09/2013 09:49 AM, Alex Efros wrote:
>> Hi!
>>
>> On Mon, Sep 09, 2013 at 09:30:56AM -0400, Michael Orlitzky wrote:
>>> That is, can I disable PT_PAX, enable XATTR_PAX, reboot, and run
>>> migrate-pax? Or might that cause problems?
>>
>> You can migrate with just one reboot, but order of actions is different:
>>
>> 1. Build new kernel with PT_PAX disabled and XATTR_PAX enabled.
>> 2. Run `migrate-pax -m`.
>> 3. Reboot using new kernel.
>
> Thanks, I'll give it a try (on the router in the building where I have
> keys, first...).
>
>
>> I'm not really sure, but you may also need to add PAX_MARKINGS="XT" into
>> /etc/make.conf.
>>
>
> pax-utils.eclass has this to say:
>
> To control what markings are made, set PAX_MARKINGS in /etc/portage
> /make.conf to contain either "PT", "XT" or "none". The default is to
> attempt both PT_PAX and XATTR_PAX.
>
> But then again, right below that, I see,
>
> # @ECLASS-VARIABLE: PAX_MARKINGS
> # @DESCRIPTION:
> # Control which markings are made:
> # PT = PT_PAX markings, XT = XATTR_PAX markings
> # Default to PT markings.
> PAX_MARKINGS=${PAX_MARKINGS:="PT"}
>
> So I'm not really sure either.
>

That was my mistake. When I dropped XT I forgot to update the comment.
We tried XT right off the bat, but discovered a couple of problems: 1)
install doesn't preserve xattr. we have a solution but it isn't working
that well, and 2) there were lots of warning thrown for non hardened
users which annoyed them. So we dropped to just PT.


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 09/09/2013 01:47 PM, Anthony G. Basile wrote:
>
> That was my mistake. When I dropped XT I forgot to update the comment.
> We tried XT right off the bat, but discovered a couple of problems: 1)
> install doesn't preserve xattr. we have a solution but it isn't working
> that well, and 2) there were lots of warning thrown for non hardened
> users which annoyed them. So we dropped to just PT.
>

What do you recommend then? Stick with PT_PAX until the install thing is
fixed, and then add PAX_MARKINGS=XT to make.conf?

On 09/09/2013 01:56 PM, Michael Orlitzky wrote:
> On 09/09/2013 01:47 PM, Anthony G. Basile wrote:
>>
>> That was my mistake. When I dropped XT I forgot to update the comment.
>> We tried XT right off the bat, but discovered a couple of problems: 1)
>> install doesn't preserve xattr. we have a solution but it isn't working
>> that well, and 2) there were lots of warning thrown for non hardened
>> users which annoyed them. So we dropped to just PT.
>>
>
> What do you recommend then? Stick with PT_PAX until the install thing is
> fixed, and then add PAX_MARKINGS=XT to make.conf?
>
>

You can use XT_PAX provided you're not running something like a
tinderbox, ie doing massive amounts of ebuilds. The problem is that
install is being wrapped by install.py. As a result every instance of
install mean invoking the python interpreter. With lots and lots of
installs, this adds up to being very slow.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Hi!

On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
> install is being wrapped by install.py. As a result every instance of
> install mean invoking the python interpreter. With lots and lots of
> installs, this adds up to being very slow.

Why not just add a patch for `install`? Even if you will just exec
`paxctl-ng` at end of `install` it still will be much faster.

--
WBR, Alex.

On 09/09/2013 05:26 PM, Anthony G. Basile wrote:
>
> You can use XT_PAX provided you're not running something like a
> tinderbox, ie doing massive amounts of ebuilds. The problem is that
> install is being wrapped by install.py. As a result every instance of
> install mean invoking the python interpreter. With lots and lots of
> installs, this adds up to being very slow.
>

Ok, thanks. These are all servers and installing anything is out of the
ordinary. Should I add a note about PAX_MARKINGS to the wiki, or is
there a plan to make that unnecessary (again)?

On 09/09/2013 07:45 PM, Michael Orlitzky wrote:
> On 09/09/2013 05:26 PM, Anthony G. Basile wrote:
>>
>> You can use XT_PAX provided you're not running something like a
>> tinderbox, ie doing massive amounts of ebuilds. The problem is that
>> install is being wrapped by install.py. As a result every instance of
>> install mean invoking the python interpreter. With lots and lots of
>> installs, this adds up to being very slow.
>>
>
> Ok, thanks. These are all servers and installing anything is out of the
> ordinary. Should I add a note about PAX_MARKINGS to the wiki, or is
> there a plan to make that unnecessary (again)?
>

Feel free to add any documentation you guys think is lacking.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 09/09/2013 06:06 PM, Alex Efros wrote:
> Hi!
>
> On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
>> install is being wrapped by install.py. As a result every instance of
>> install mean invoking the python interpreter. With lots and lots of
>> installs, this adds up to being very slow.
>
> Why not just add a patch for `install`? Even if you will just exec
> `paxctl-ng` at end of `install` it still will be much faster.
>

We decided that changing the default behavior of install was not a good
idea. See [1]

There are places where we have to do pax markings before install. We
could do them twice, that was the other option. When I wrote the python
wrapper, I had no idea it was going to be this slow.

Ref
[1] https://bugs.gentoo.org/show_bug.cgi?id=470660

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

2013.Szeptember 10.(K) 13:50 időpontban Anthony G. Basile ezt írta:
> On 09/09/2013 06:06 PM, Alex Efros wrote:
>> Hi!
>>
>> On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
>>> install is being wrapped by install.py. As a result every instance of
>>> install mean invoking the python interpreter. With lots and lots of
>>> installs, this adds up to being very slow.
>>
>> Why not just add a patch for `install`? Even if you will just exec
>> `paxctl-ng` at end of `install` it still will be much faster.
>>
>
> We decided that changing the default behavior of install was not a good
> idea. See [1]
>
> There are places where we have to do pax markings before install. We
> could do them twice, that was the other option. When I wrote the python
> wrapper, I had no idea it was going to be this slow.
>
> Ref
> [1] https://bugs.gentoo.org/show_bug.cgi?id=470660
>
> --
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
>

Dear blueness: what is the future perspective?

--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

On 09/10/2013 07:44 AM, Anthony G. Basile wrote:
> On 09/09/2013 07:45 PM, Michael Orlitzky wrote:
>> On 09/09/2013 05:26 PM, Anthony G. Basile wrote:
>>>
>>> You can use XT_PAX provided you're not running something like a
>>> tinderbox, ie doing massive amounts of ebuilds. The problem is that
>>> install is being wrapped by install.py. As a result every instance of
>>> install mean invoking the python interpreter. With lots and lots of
>>> installs, this adds up to being very slow.
>>>
>>
>> Ok, thanks. These are all servers and installing anything is out of the
>> ordinary. Should I add a note about PAX_MARKINGS to the wiki, or is
>> there a plan to make that unnecessary (again)?
>>
>
> Feel free to add any documentation you guys think is lacking.
>

Whoops, I don't have rights to edit the page. I wrote the blurb, though:

5. Update make.conf.

To prevent warnings for non-hardened users, portage defaults to PT_PAX
markings when installing packages. If the migration was successful and
your kernel is respecting the new XATTR_PAX markings, you can tell
portage to use them in the future. Simply set,

{{File|/etc/portage/make.conf||<pre>
PAX_MARKINGS="XT"
</pre>}}

in your make.conf.

On Sep 10, 2013 3:03 PM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 09/10/2013 07:44 AM, Anthony G. Basile wrote:
> > On 09/09/2013 07:45 PM, Michael Orlitzky wrote:
> >> On 09/09/2013 05:26 PM, Anthony G. Basile wrote:
> >>>
> >>> You can use XT_PAX provided you're not running something like a
> >>> tinderbox, ie doing massive amounts of ebuilds. The problem is that
> >>> install is being wrapped by install.py. As a result every instance of
> >>> install mean invoking the python interpreter. With lots and lots of
> >>> installs, this adds up to being very slow.
> >>>
> >>
> >> Ok, thanks. These are all servers and installing anything is out of the
> >> ordinary. Should I add a note about PAX_MARKINGS to the wiki, or is
> >> there a plan to make that unnecessary (again)?
> >>
> >
> > Feel free to add any documentation you guys think is lacking.
> >
>
> Whoops, I don't have rights to edit the page. I wrote the blurb, though:
>
> 5. Update make.conf.
>
> To prevent warnings for non-hardened users, portage defaults to PT_PAX
> markings when installing packages. If the migration was successful and
> your kernel is respecting the new XATTR_PAX markings, you can tell
> portage to use them in the future. Simply set,
>
> {{File|/etc/portage/make.conf||<pre>
> PAX_MARKINGS="XT"
> </pre>}}
>
> in your make.conf.
>
>

Yes, everything under Project: namespace is only writable for developers.

If the project developers don't mind end user changes the documents can be
moved to the general location (like we did with many SELinux related
documents).

You can always put edits in your personal space and have a developer review
and integrate if needed, but my preference is to move those documents to
the main namespace.

Wkr,
Sven

On 09/10/2013 09:08 AM, Sven Vermeulen wrote:
> On Sep 10, 2013 3:03 PM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>>
>> On 09/10/2013 07:44 AM, Anthony G. Basile wrote:
>>> On 09/09/2013 07:45 PM, Michael Orlitzky wrote:
>>>> On 09/09/2013 05:26 PM, Anthony G. Basile wrote:
>>>>>
>>>>> You can use XT_PAX provided you're not running something like a
>>>>> tinderbox, ie doing massive amounts of ebuilds. The problem is that
>>>>> install is being wrapped by install.py. As a result every instance of
>>>>> install mean invoking the python interpreter. With lots and lots of
>>>>> installs, this adds up to being very slow.
>>>>>
>>>>
>>>> Ok, thanks. These are all servers and installing anything is out of the
>>>> ordinary. Should I add a note about PAX_MARKINGS to the wiki, or is
>>>> there a plan to make that unnecessary (again)?
>>>>
>>>
>>> Feel free to add any documentation you guys think is lacking.
>>>
>>
>> Whoops, I don't have rights to edit the page. I wrote the blurb, though:
>>
>> 5. Update make.conf.
>>
>> To prevent warnings for non-hardened users, portage defaults to PT_PAX
>> markings when installing packages. If the migration was successful and
>> your kernel is respecting the new XATTR_PAX markings, you can tell
>> portage to use them in the future. Simply set,
>>
>> {{File|/etc/portage/make.conf||<pre>
>> PAX_MARKINGS="XT"
>> </pre>}}
>>
>> in your make.conf.
>>
>>
>
> Yes, everything under Project: namespace is only writable for developers.
>
> If the project developers don't mind end user changes the documents can be
> moved to the general location (like we did with many SELinux related
> documents).
>
> You can always put edits in your personal space and have a developer review
> and integrate if needed, but my preference is to move those documents to
> the main namespace.
>
> Wkr,
> Sven
>

Sven go ahead and make them like the SELinux docs. Is there any way to
monitor the changes, eg by having emails sent the way the torproject
wiki does?

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 09/10/2013 08:52 AM, "Tóth Attila" wrote:
> 2013.Szeptember 10.(K) 13:50 időpontban Anthony G. Basile ezt írta:
>> On 09/09/2013 06:06 PM, Alex Efros wrote:
>>> Hi!
>>>
>>> On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
>>>> install is being wrapped by install.py. As a result every instance of
>>>> install mean invoking the python interpreter. With lots and lots of
>>>> installs, this adds up to being very slow.
>>>
>>> Why not just add a patch for `install`? Even if you will just exec
>>> `paxctl-ng` at end of `install` it still will be much faster.
>>>
>>
>> We decided that changing the default behavior of install was not a good
>> idea. See [1]
>>
>> There are places where we have to do pax markings before install. We
>> could do them twice, that was the other option. When I wrote the python
>> wrapper, I had no idea it was going to be this slow.
>>
>> Ref
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=470660
>>
>> --
>> Anthony G. Basile, Ph. D.
>> Chair of Information Technology
>> D'Youville College
>> Buffalo, NY 14201
>> (716) 829-8197
>>
>
> Dear blueness: what is the future perspective?
>

Well right now, I don't have a hard plan. I'll need to speak with Zac
Medico how he might want to replace that wrapper. It should be possible
to just drop in a compiled version of install with our patch that
preserves *just* user.pax.flags.

cc-ing Zac.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On Sep 10, 2013 3:59 PM, "Anthony G. Basile" <basile@opensource.dyc.edu>
wrote:
>>
>> If the project developers don't mind end user changes the documents can
be
>> moved to the general location (like we did with many SELinux related
>> documents).
>>
>> You can always put edits in your personal space and have a developer
review
>> and integrate if needed, but my preference is to move those documents to
>> the main namespace.
> Sven go ahead and make them like the SELinux docs. Is there any way to
monitor the changes, eg by having emails sent the way the torproject wiki
does?

I don't know about e-mail, but you can watch them and then see the changes
made (chronologically) through your personal watchlist page.

Shall I take the liberty of moving all those that I don't think need to
remain on the project namespace (like policies or so)? Or would you rather
have me send the list that I think can be moved first for review?

Wkr,
Sven

2013.Szeptember 10.(K) 16:00 időpontban Anthony G. Basile ezt írta:
> On 09/10/2013 08:52 AM, "Tóth Attila" wrote:
>> 2013.Szeptember 10.(K) 13:50 időpontban Anthony G. Basile ezt írta:
>>> On 09/09/2013 06:06 PM, Alex Efros wrote:
>>>> Hi!
>>>>
>>>> On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
>>>>> install is being wrapped by install.py. As a result every instance
>>>>> of
>>>>> install mean invoking the python interpreter. With lots and lots of
>>>>> installs, this adds up to being very slow.
>>>>
>>>> Why not just add a patch for `install`? Even if you will just exec
>>>> `paxctl-ng` at end of `install` it still will be much faster.
>>>>
>>>
>>> We decided that changing the default behavior of install was not a good
>>> idea. See [1]
>>>
>>> There are places where we have to do pax markings before install. We
>>> could do them twice, that was the other option. When I wrote the
>>> python
>>> wrapper, I had no idea it was going to be this slow.
>>>
>>> Ref
>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=470660
>>>
>>> --
>>> Anthony G. Basile, Ph. D.
>>> Chair of Information Technology
>>> D'Youville College
>>> Buffalo, NY 14201
>>> (716) 829-8197
>>>
>>
>> Dear blueness: what is the future perspective?
>>
>
> Well right now, I don't have a hard plan. I'll need to speak with Zac
> Medico how he might want to replace that wrapper. It should be possible
> to just drop in a compiled version of install with our patch that
> preserves *just* user.pax.flags.

Sounds great. I'll surely test it as soon as it appears in the hardened
overlay or such.

Thx: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

On 09/10/2013 10:03 AM, Sven Vermeulen wrote:
> On Sep 10, 2013 3:59 PM, "Anthony G. Basile" <basile@opensource.dyc.edu>
> wrote:
>>>
>>> If the project developers don't mind end user changes the documents can
> be
>>> moved to the general location (like we did with many SELinux related
>>> documents).
>>>
>>> You can always put edits in your personal space and have a developer
> review
>>> and integrate if needed, but my preference is to move those documents to
>>> the main namespace.
>> Sven go ahead and make them like the SELinux docs. Is there any way to
> monitor the changes, eg by having emails sent the way the torproject wiki
> does?
>
> I don't know about e-mail, but you can watch them and then see the changes
> made (chronologically) through your personal watchlist page.
>
> Shall I take the liberty of moving all those that I don't think need to
> remain on the project namespace (like policies or so)? Or would you rather
> have me send the list that I think can be moved first for review?
>
> Wkr,
> Sven
>

I trust your judgment, ie I'm too lazy to watch over you :P

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 09/10/2013 10:40 AM, "Tóth Attila" wrote:
> 2013.Szeptember 10.(K) 16:00 időpontban Anthony G. Basile ezt írta:
>> On 09/10/2013 08:52 AM, "Tóth Attila" wrote:
>>> 2013.Szeptember 10.(K) 13:50 időpontban Anthony G. Basile ezt írta:
>>>> On 09/09/2013 06:06 PM, Alex Efros wrote:
>>>>> Hi!
>>>>>
>>>>> On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
>>>>>> install is being wrapped by install.py. As a result every instance
>>>>>> of
>>>>>> install mean invoking the python interpreter. With lots and lots of
>>>>>> installs, this adds up to being very slow.
>>>>>
>>>>> Why not just add a patch for `install`? Even if you will just exec
>>>>> `paxctl-ng` at end of `install` it still will be much faster.
>>>>>
>>>>
>>>> We decided that changing the default behavior of install was not a good
>>>> idea. See [1]
>>>>
>>>> There are places where we have to do pax markings before install. We
>>>> could do them twice, that was the other option. When I wrote the
>>>> python
>>>> wrapper, I had no idea it was going to be this slow.
>>>>
>>>> Ref
>>>> [1] https://bugs.gentoo.org/show_bug.cgi?id=470660
>>>>
>>>> --
>>>> Anthony G. Basile, Ph. D.
>>>> Chair of Information Technology
>>>> D'Youville College
>>>> Buffalo, NY 14201
>>>> (716) 829-8197
>>>>
>>>
>>> Dear blueness: what is the future perspective?
>>>
>>
>> Well right now, I don't have a hard plan. I'll need to speak with Zac
>> Medico how he might want to replace that wrapper. It should be possible
>> to just drop in a compiled version of install with our patch that
>> preserves *just* user.pax.flags.
>
> Sounds great. I'll surely test it as soon as it appears in the hardened
> overlay or such.
>
> Thx: Dw.
>

Actually that's probably the way to start this. I can put a version on
install on the hardened overlay name it something like install-portage.
It will *not* install over install, but install somewhere in the
portage path where we now have install.py. Then we can test my patch
against install.


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 10/09/13 10:03 AM, Sven Vermeulen wrote:
> On Sep 10, 2013 3:59 PM, "Anthony G. Basile" <basile@opensource.dyc.edu>
> wrote:
>>>
>>> If the project developers don't mind end user changes the documents can
> be
>>> moved to the general location (like we did with many SELinux related
>>> documents).
>>>
>>> You can always put edits in your personal space and have a developer
> review
>>> and integrate if needed, but my preference is to move those documents to
>>> the main namespace.
>> Sven go ahead and make them like the SELinux docs. Is there any way to
> monitor the changes, eg by having emails sent the way the torproject wiki
> does?
>
> I don't know about e-mail, but you can watch them and then see the changes
> made (chronologically) through your personal watchlist page.
>
> Shall I take the liberty of moving all those that I don't think need to
> remain on the project namespace (like policies or so)? Or would you rather
> have me send the list that I think can be moved first for review?
>
> Wkr,
> Sven
>

MediaWiki can be configured to send email whenever a page or file on
your watchlist is changed.

[[Special:Preferences]] - "Email me when a page or file on my watchlist
is changed" funnily enough

You can also configure it to automatically:

[[Special:Preferences]] Watchlist - "Add pages and files I edit to my
watchlist"

You can also use RSS to read changes to your watchlist, but I find this
arbitrarily unreliable (at least on enwp).

Hi!

On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
> You can use XT_PAX provided you're not running something like a
> tinderbox, ie doing massive amounts of ebuilds. The problem is that
> install is being wrapped by install.py. As a result every instance of
> install mean invoking the python interpreter. With lots and lots of
> installs, this adds up to being very slow.

I think it may be possible to add very ease and effective optimization -
call install.py only for executable files and use /usr/bin/install for all
other files. This can be implemented in single line in
/usr/lib/portage/bin/ebuild-helpers/xattr/install. Also it may make sense
to rewrite /usr/lib/portage/bin/ebuild-helpers/xattr/install in C.

--
WBR, Alex.

On 10/04/2013 12:23 AM, Alex Efros wrote:
> Hi!
>
> On Mon, Sep 09, 2013 at 05:26:57PM -0400, Anthony G. Basile wrote:
>> You can use XT_PAX provided you're not running something like a
>> tinderbox, ie doing massive amounts of ebuilds. The problem is that
>> install is being wrapped by install.py. As a result every instance of
>> install mean invoking the python interpreter. With lots and lots of
>> installs, this adds up to being very slow.
>
> I think it may be possible to add very ease and effective optimization -
> call install.py only for executable files and use /usr/bin/install for all
> other files. This can be implemented in single line in
> /usr/lib/portage/bin/ebuild-helpers/xattr/install. Also it may make sense
> to rewrite /usr/lib/portage/bin/ebuild-helpers/xattr/install in C.
>

I was hoping a greater generalization than just user.pax.flags so that
we can have full end-to-end support for xattrs of any name space we choose.

The problem that I have not had time to face is, how do I include a
compiled version of install at
/usr/lib/portage/bin/ebuild-helpers/xattr/install? I know how to patch
the C, and its is not hard to maintain a separate version of install
from coreutils, but how do I include this in portage so that when you
emerge portage you get this compiled version?

I'm cc-ing zmedico. The guru here.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197