The first problem is, with the current net-im/skype-2.2.0.35-r1 ebuild emerge skype with USE='pax-kernel' would result in a sandbox violation: ---------------------------- >>> Install skype-2.2.0.35-r1 into /var/tmp/portage/net-im/skype-2.2.0.35-r1/image/ category net-im ... * PT PaX marking -m * /opt/skype/skype ACCESS DENIED open_wr: /opt/skype/skype ACCESS DENIED open_wr: /opt/skype/skype ACCESS DENIED open_wr: /opt/skype/skype ---------------------------- The cause is this line in the ebuild: pax-mark m /opt/skype/skype || die There should be a "${D}" before /opt/skype/skype. However there comes the second problem: pax-mark m "${D}/opt/skype/skype" does not actually work, since according to pax-utils.eclass, pax-mark m "${D}/opt/skype/skype" would firstly cause it to execute: paxctl -qm /var/tmp/portage/net-im/skype-2.2.0.35-r1/image//opt/skype/skype It would fail since "file /opt/skype/skype does not have a PT_PAX_FLAGS program header", then it executes: paxctl -qcm /var/tmp/portage/net-im/skype-2.2.0.35-r1/image//opt/skype/skype Which would be succesful, so pax-mark.eclass considers it's working and returns to the ebuild. Nonetheless, a "paxctl -cm"-ed skype does not run. Skype tells you the binary is corrupted and you should reinstall skype, which was once discussed here: https://bugs.gentoo.org/show_bug.cgi?id=302589 The solution is what mori rámar pointed out in the comment #38: pax-mark Cm "${D}/opt/skype/skype" || die And the third problem appears. I have paxctl-0.6 installed, currently it's ~x86/~amd64, and seemingly for paxctl-0.6, paxctl -Cm "/opt/skype/skype" breaks the skype executable somehow. ---------------------------- # paxctl -Cm /opt/skype/skype file /opt/skype/skype got a new PT_PAX_FLAGS program header # paxctl -v /opt/skype/skype PaX control v0.6 Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu> file /opt/skype/skype is not a valid ELF executable (invalid SHT_ entry:0) ---------------------------- Since paxctl failed, the -m is not applied, and skype gets killed for allocating RWX memory on a PaX-enabled kernel. And downgrading paxctl to 0.5 fixes it for me. So it might make sense to DEPEND on pax-kernel? ( <sys-apps/paxctl-0.6 ) for now in the skype ebuild, unless you guys could figure what prevented /opt/skype/skype from being successfully "paxctl -Cm"-ed for paxctl-0.6. Reproducible: Always
Fixed the paxctl and the ${D} error. Going to look into the paxctl-0.6 problem more. ${D} should not have been needed in eapi4 I thought :|
> And the third problem appears. I have paxctl-0.6 installed, currently it's > ~x86/~amd64, and seemingly for paxctl-0.6, paxctl -Cm "/opt/skype/skype" > breaks the skype executable somehow. > That's why paxctl-0.6 is marked ~arch. We need to fix this for paxctl-0.5. Since paxctl -c/-C is on the way out (slowly but surely) and we will have a new way of doing pax markings for binaries that don't have PT_PAX hearders (no not EI_PAX either) we may never stabilize paxctl-0.6.
Same issue. Downgrading paxctl to 0.5 has solved the problem.
I'm gonna go ahead and close the bug here since the pax issue is unrelated and the sandbox breakage is fixed, so...
