Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 564328 - Failed to set XATTR_PAX markings error could be clarified better
Summary: Failed to set XATTR_PAX markings error could be clarified better
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Gentoo Linux Hardened Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 427888 578362
  Show dependency tree
 
Reported: 2015-10-28 14:38 UTC by Anton Bolshakov
Modified: 2018-09-11 15:26 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Bolshakov 2015-10-28 14:38:21 UTC
make: Leaving directory '/var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/work/john-1.7.9/src'
>>> Source compiled.
>>> Test phase [not enabled]: app-crypt/johntheripper-1.7.9-r10

>>> Install johntheripper-1.7.9-r10 into /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/ category app-crypt
 *      /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john
 TYPE    PAX   FILE
ET_EXEC --mxer /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john
 *      /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john
 * XT PaX marking -mre /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john with setfattr
setfattr: /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john: Operation not supported
 * Failed to set XATTR_PAX markings -mre /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john.
 * ERROR: app-crypt/johntheripper-1.7.9-r10::gentoo failed (install phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line  93:  Called src_install
 *   environment, line 2647:  Called die
 * The specific snippet of code:
 *       pax-mark -mr "${ED}usr/sbin/john" || die;
 *
 * If you need support, post the output of `emerge --info '=app-crypt/johntheripper-1.7.9-r10::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=app-crypt/johntheripper-1.7.9-r10::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/temp/environment'.
 * Working directory: '/var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/work/john-1.7.9'
 * S: '/var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/work/john-1.7.9'

bash# setfattr -mre /var/tmp/portage/app-crypt/johntheripper-1.7.9-r10/image/usr/sbin/john
setfattr: invalid option -- 'm'


emerge --info
Portage 2.2.20.1 (python 2.7.10-final-0, default/linux/amd64/13.0, gcc-4.9.3, glibc-2.21-r1, 3.11.0-cloud x86_64)
=================================================================
System uname: Linux-3.11.0-cloud-x86_64-Intel-R-_Xeon-R-_CPU_E5-2640_0_@_2.50GHz-with-gentoo-2.2
KiB Mem:     2043604 total,   1122880 free
KiB Swap:     506040 total,    504168 free
Timestamp of repository gentoo: Wed, 28 Oct 2015 03:00:01 +0000
sh bash 4.3_p39
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:          4.3_p39::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.10::gentoo, 3.4.3::gentoo
dev-util/cmake:           3.3.1-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.17::gentoo
sys-apps/sandbox:         2.6-r1::gentoo
sys-devel/autoconf:       2.69::gentoo
sys-devel/automake:       1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.9.3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers)
sys-libs/glibc:           2.21-r1::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/easy-rsa"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
Comment 1 Alexander Tsoy 2015-10-28 15:25:50 UTC
Your PORTAGE_TMPDIR filesystem seems doesn't support xattrs or doesn't support "user." namespace. I think that "|| die" after "pax-mark" must be killed.
Comment 2 Anton Bolshakov 2015-10-28 15:46:00 UTC
Yes, you are right, user ns is not enabled:

 zcat /proc/config.gz | grep -i USER_NS

But this is a VPS hosting so I can't simply enable it.

Please remove the "die" command.
Comment 3 Alexander Tsoy 2015-10-28 18:40:02 UTC
(In reply to Anton Bolshakov from comment #2)
> Yes, you are right, user ns is not enabled:
> 
>  zcat /proc/config.gz | grep -i USER_NS

I meant extended attributes user namespace (user.*). For example:

$ sudo getfattr -d /usr/lib64/firefox/firefox
getfattr: Removing leading '/' from absolute path names
# file: usr/lib64/firefox/firefox
user.pax.flags="em"
Comment 4 Anton Bolshakov 2015-10-30 06:04:46 UTC
bash# getfattr -d /full/path

FYI, the command above returns nothing on that box.
Comment 5 Anton Bolshakov 2015-11-26 02:49:03 UTC
ZC, Could you please commit this trivial fix:

remove "|| die" in the "pax-mark" line

Thank you
Comment 6 Rick Farina (Zero_Chaos) gentoo-dev 2015-11-26 17:55:29 UTC
pax-mark should be able to handle things properly.  I'm not just removing || die.

Hardened team, is this a bug?
Comment 7 Anthony Basile gentoo-dev 2015-11-26 18:01:56 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #6)
> pax-mark should be able to handle things properly.  I'm not just removing ||
> die.
> 
> Hardened team, is this a bug?

The problem is no user.pax xattrs on tmpfs.  Since this is a vps and the kernel can't be changed, I recommend not using tmpfs on /tmp.
Comment 8 Rick Farina (Zero_Chaos) gentoo-dev 2015-11-26 21:40:36 UTC
(In reply to Anthony Basile from comment #7)
> (In reply to Rick Farina (Zero_Chaos) from comment #6)
> > pax-mark should be able to handle things properly.  I'm not just removing ||
> > die.
> > 
> > Hardened team, is this a bug?
> 
> The problem is no user.pax xattrs on tmpfs.  Since this is a vps and the
> kernel can't be changed, I recommend not using tmpfs on /tmp.

but is this something that pax-mark should be detecting and not dying on?  or should pax-mark die on this and we leave the user to reconfigure their system sanely?
Comment 9 Anton Bolshakov 2015-11-26 22:43:28 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #6)
> pax-mark should be able to handle things properly.  I'm not just removing ||
> die.
> 
> Hardened team, is this a bug?

This box is not hardened and setfattr is not required for normal run of the software. So please remove the die call now, it is inline with recent change anyway. 

The pax-mark eclass can be modified later to issue a warning if you want.
Comment 10 Rick Farina (Zero_Chaos) gentoo-dev 2015-11-27 17:09:37 UTC
(In reply to Anton Bolshakov from comment #9)
> This box is not hardened and setfattr is not required for normal run of the
> software.

then pax-mark should handle it correctly and not die, which would make this a hardened bug

> So please remove the die call now, it is inline with recent change
> anyway. 

No, you can do that locally while we fix the eclass properly if it is an emergency, it's not like you don't know how.
Comment 11 Anthony Basile gentoo-dev 2015-11-27 18:17:26 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #10)
> (In reply to Anton Bolshakov from comment #9)
> > This box is not hardened and setfattr is not required for normal run of the
> > software.
> 
> then pax-mark should handle it correctly and not die, which would make this
> a hardened bug

I can add intelligence here, but to be clear, under what conditions do we want the || die to be triggered?  I mean, I can have pax-mark always return 0 in which case || die will never be triggered.
Comment 12 Anthony Basile gentoo-dev 2015-11-27 18:21:49 UTC
(In reply to Anton Bolshakov from comment #9)
> (In reply to Rick Farina (Zero_Chaos) from comment #6)
> > pax-mark should be able to handle things properly.  I'm not just removing ||
> > die.
> > 
> > Hardened team, is this a bug?
> 
> This box is not hardened and setfattr is not required for normal run of the
> software. So please remove the die call now, it is inline with recent change
> anyway. 
> 
> The pax-mark eclass can be modified later to issue a warning if you want.

can you please try adding PAX_MARKINGS="" to your make.conf.  this will skip all pax markings.  See if that fixes it.
Comment 13 Anton Bolshakov 2015-11-28 13:39:08 UTC
(In reply to Anthony Basile from comment #12)
> can you please try adding PAX_MARKINGS="" to your make.conf.  this will skip
> all pax markings.  See if that fixes it.

The empty value didn't work. I specified:
PAX_MARKINGS="PT_PAX"

and it worked. So, can it be done in the eclass automatically?
Comment 14 Anton Bolshakov 2015-11-28 13:43:37 UTC
FYI, "none" works as well.
Comment 15 Anthony Basile gentoo-dev 2015-11-28 14:12:07 UTC
(In reply to Anton Bolshakov from comment #13)
> (In reply to Anthony Basile from comment #12)
> > can you please try adding PAX_MARKINGS="" to your make.conf.  this will skip
> > all pax markings.  See if that fixes it.
> 
> The empty value didn't work. I specified:
> PAX_MARKINGS="PT_PAX"
> 
> and it worked. So, can it be done in the eclass automatically?

PT_PAX is meaningless here.  Read the top of the eclass.

(In reply to Anton Bolshakov from comment #14)
> FYI, "none" works as well.

Correct, read the top of the eclass

# 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.


I don't understand why "" didn't work, but I can add that as an option since it seems to make sense.
Comment 16 Anthony Basile gentoo-dev 2015-11-28 14:16:10 UTC
(In reply to Anthony Basile from comment #15)
> 
> I don't understand why "" didn't work, but I can add that as an option since
> it seems to make sense.

Its because of

PAX_MARKINGS=${PAX_MARKINGS:="PT XT"}
Comment 17 Anton Bolshakov 2015-11-28 14:40:22 UTC
(In reply to Anthony Basile from comment #15)
> > PAX_MARKINGS="PT_PAX"
> PT_PAX is meaningless here.  Read the top of the eclass.

PT_PAX value can be used because of the check:
  if has PT ${PAX_MARKINGS}; then
you can got lucky that PT is not included in "XATTR_PAX" string.

Anyway, thanks for the PAX_MARKINGS hint. I wasn't aware about it.
Comment 18 Anton Bolshakov 2015-11-28 14:48:00 UTC
I'm sorry, one last question before letting it go as an invalid bug.

I've seen few other packages unable to set pax-mark as well, but they would not die. An example: 
dev-lang/python/python-2.7.10-r4.ebuild
 pax-mark E python

(there is no "|| die" at the end)

This is more inconsistency. Since other eclasess does not require "die" operator anymore (emake etc) wouldn't it make sense to make it inline as well?
Comment 19 Anton Bolshakov 2015-11-28 14:52:40 UTC
there is one more point. Based on the manual, "PaX markings for hardened kernels". 

So from the user's point of view the pax-utils.eclass should not be used at all on non-hardened kernels. I'm a bit confused why I need PAX_MARKINGS settings.
Comment 20 Anthony Basile gentoo-dev 2015-11-28 15:58:26 UTC
(In reply to Anton Bolshakov from comment #18)
> I'm sorry, one last question before letting it go as an invalid bug.
> 
> I've seen few other packages unable to set pax-mark as well, but they would
> not die. An example: 
> dev-lang/python/python-2.7.10-r4.ebuild
>  pax-mark E python
> 
> (there is no "|| die" at the end)
> 
> This is more inconsistency. Since other eclasess does not require "die"
> operator anymore (emake etc) wouldn't it make sense to make it inline as
> well?

i need to go over the eclass in light of the cutover to xt pax markings only and will make it so no || die is required.

(In reply to Anton Bolshakov from comment #19)
> there is one more point. Based on the manual, "PaX markings for hardened
> kernels". 
> 
> So from the user's point of view the pax-utils.eclass should not be used at
> all on non-hardened kernels. I'm a bit confused why I need PAX_MARKINGS
> settings.

no this is wrong.  there are users that switch between hardened and vanilla kernels all the time.  so they should get the markings even if installing while using a vanilla kernel. 

gentoo is moving towards requireing xattrs for many reasons.  so turning them off in a kernel as you do is going to become increasingly unsupported.
Comment 21 Rick Farina (Zero_Chaos) gentoo-dev 2015-11-28 16:07:10 UTC
(In reply to Anthony Basile from comment #11)
> (In reply to Rick Farina (Zero_Chaos) from comment #10)
> I can add intelligence here, but to be clear, under what conditions do we
> want the || die to be triggered?  I mean, I can have pax-mark always return
> 0 in which case || die will never be triggered.

Honestly if XATTR pax is specified and XATTR is not supported the *ideal* situation would be to fail out with a message telling the user that XATTR is not supported and to enable it, or disable XT pax.  The current failure seems to have left to much to the imagination (Operation not supported) and we could easily print something useful here before dying.
Comment 22 Anthony Basile gentoo-dev 2015-11-28 16:56:50 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #21)
> (In reply to Anthony Basile from comment #11)
> > (In reply to Rick Farina (Zero_Chaos) from comment #10)
> > I can add intelligence here, but to be clear, under what conditions do we
> > want the || die to be triggered?  I mean, I can have pax-mark always return
> > 0 in which case || die will never be triggered.
> 
> Honestly if XATTR pax is specified and XATTR is not supported the *ideal*
> situation would be to fail out with a message telling the user that XATTR is
> not supported and to enable it, or disable XT pax.  The current failure
> seems to have left to much to the imagination (Operation not supported) and
> we could easily print something useful here before dying.

i can intercept the "Operation not supported" but that doesn't answer the question.  what should be returned by pax-mark?
Comment 23 Rick Farina (Zero_Chaos) gentoo-dev 2015-12-01 04:40:02 UTC
(In reply to Anthony Basile from comment #22)
> (In reply to Rick Farina (Zero_Chaos) from comment #21)
> > (In reply to Anthony Basile from comment #11)
> > > (In reply to Rick Farina (Zero_Chaos) from comment #10)
> > > I can add intelligence here, but to be clear, under what conditions do we
> > > want the || die to be triggered?  I mean, I can have pax-mark always return
> > > 0 in which case || die will never be triggered.
> > 
> > Honestly if XATTR pax is specified and XATTR is not supported the *ideal*
> > situation would be to fail out with a message telling the user that XATTR is
> > not supported and to enable it, or disable XT pax.  The current failure
> > seems to have left to much to the imagination (Operation not supported) and
> > we could easily print something useful here before dying.
> 
> i can intercept the "Operation not supported" but that doesn't answer the
> question.  what should be returned by pax-mark?

something to the effect of "User has requested XT pax marking but it is not supported on the target filesystem, please enable it or disable XT pax by setting PAX_MARKINGS="PT"" and then exiting 1
Comment 24 Alexander Tsoy 2015-12-01 21:32:16 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #23)
> ... and then exiting 1

Only a few packages has '|| die' after pax-mark.
Comment 25 Anthony Basile gentoo-dev 2016-01-13 20:38:23 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #21)
> (In reply to Anthony Basile from comment #11)
> > (In reply to Rick Farina (Zero_Chaos) from comment #10)
> > I can add intelligence here, but to be clear, under what conditions do we
> > want the || die to be triggered?  I mean, I can have pax-mark always return
> > 0 in which case || die will never be triggered.
> 
> Honestly if XATTR pax is specified and XATTR is not supported the *ideal*
> situation would be to fail out with a message telling the user that XATTR is
> not supported and to enable it, or disable XT pax.  The current failure
> seems to have left to much to the imagination (Operation not supported) and
> we could easily print something useful here before dying.

pax-utils.eclass should now emit an easier to understand error.  do you want to check and close this bug if you're okay with what i did.
Comment 26 Anthony Basile gentoo-dev 2016-03-27 15:52:08 UTC
@mrueg you just added yourself to this bug, is there still a problem with not enough error message?  if so how did you hit it?
Comment 27 Manuel Rüger (RETIRED) gentoo-dev 2016-03-27 15:57:51 UTC
(In reply to Anthony Basile from comment #26)
> @mrueg you just added yourself to this bug, is there still a problem with
> not enough error message?  if so how did you hit it?

I got bitten in https://bugs.gentoo.org/show_bug.cgi?id=578362
Comment 28 Mike Auty gentoo-dev 2016-12-17 21:36:24 UTC
Sorry, I got directed to this bug recently after hitting the unexpected death of johntheripper-1.8.0-r1 in the pentoo overlay.

I run an unhardened mainline kernel (so no user xattr for tmpfs patch applied), with tmpfs for PORTAGE_TMPDIR because I'm entirely on SSDs.  So far, this is the only program I install which dies at pax-mark rather than just providing the warning.  It sounds from comment 20 as though the eclass was being reworked so that "|| die" was no longer necessary in the ebuild.  It's not clear then why the ebuilds still feature "|| die".

Has that change been made (in which case, the ebuild needs the "|| die" consequences removing), or hasn't the change been made (in which case, a status update would be useful)?

Also if anyone has any information on when/whether the tmpfs user xattr patch will get put into mainline and the problem will go away permanently, that'd be good to know too.  5:)
Comment 29 Mart Raudsepp gentoo-dev 2017-08-01 03:44:22 UTC
*** Bug 626736 has been marked as a duplicate of this bug. ***