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"
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.
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.
(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"
bash# getfattr -d /full/path FYI, the command above returns nothing on that box.
ZC, Could you please commit this trivial fix: remove "|| die" in the "pax-mark" line Thank you
pax-mark should be able to handle things properly. I'm not just removing || die. Hardened team, is this a bug?
(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.
(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?
(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.
(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.
(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.
(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.
(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?
FYI, "none" works as well.
(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.
(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"}
(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.
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?
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.
(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.
(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.
(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?
(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
(In reply to Rick Farina (Zero_Chaos) from comment #23) > ... and then exiting 1 Only a few packages has '|| die' after pax-mark.
(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.
@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?
(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
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:)
*** Bug 626736 has been marked as a duplicate of this bug. ***
