paxctl-ng will not accomplish anything if told to update PT_PAX_FLAGS for a binary that has no PT_PAX_FLAGS header, but it will return success. This in turn makes paxmark from the current pax-utils.eclass silently not do the right thing in certain circumstances. My impression is that the build system is "always" expected to create headers that pax-mark will then be able to modify. But this expectation isn't always met, such as for -bin packages. For example, www-apps/kibana-bin-5.2.2 bundles a node binary: /opt/kibana/node/bin/node. The ebuild correctly calls paxmark m .../node, but the node binary has no PT_PAX_FLAGS header, therefore that call paxmark does nothing (on a system with PAX_MARKINGS="PT") and the resulting installed executable fails to run: # egrep PAX_MARK /etc/portage/make.conf PAX_MARKINGS="PT" # egrep pax kibana-bin-5.2.2.ebuild inherit pax-utils user pax-mark m "${ED%/}/opt/${MY_PN}/node/bin/node" # ebuild kibana-bin-5.2.2.ebuild compile [snip] # paxctl-ng -v /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node: PT_PAX : not found XATTR_PAX : not found # ebuild --debug kibana-bin-5.2.2.ebuild install >~/kibana_install.log 2>&1 && echo success success # egrep -A1 '^\+ paxctl' ~/kibana_install.log + paxctl -qm /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node + type -p paxctl-ng + paxctl-ng -L + einfo 'PT_PAX marking -m /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node with paxctl-ng' -- + paxctl-ng -L -m /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node + continue The above comes from pax-utils.eclass, which has had some relevant changes recently. Just re-demonstrating manually: # paxctl-ng -L -m /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node && echo call succeeded but not really call succeeded but not really # paxctl-ng -v /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node /var/tmp/portage/www-apps/kibana-bin-5.2.2/image/opt/kibana/node/bin/node: PT_PAX : not found XATTR_PAX : not found Note that prior to paxctl-ng, old paxctl is tried. The initial paxctl call correctly fails, so we move on to paxctl-ng. pax-utils.eclass used to call paxctl -C (to create/convert a PT_PAX header) if the first paxctl command failed. However that was changed with commit 5bd65cd07e1d72c1a5e3cb12453ac2077425842e when resolving bug #590422. paxctl-ng does not try to create a header if one does not exist, and that is a decision not a bug. But returning success is a bug, because it makes pax-utils.eclass think that it has successfully marked the binary. I think this is the root cause of at least one other pending issue, such as this comment in that other bug: https://bugs.gentoo.org/show_bug.cgi?id=590422#c43 Finally, it is not clear to me if pax-utils.eclass would actually create a PT_PAX_FLAGS header and set the flags in it, if this behavior of paxctl-ng was different (but at least/maybe it would fail in a meaningful way). Or if there's something different that .ebuild's for -bin packages containing binaries without PT_PAX_FLAGS should do than what the kibana-bin ebuild does. But if not, that's probably different bug report(s).
Looking at the source for paxctl-ng.c, I think in set_pt_flags it is: - pulling a list of ELF headers (elf_getphdrnum call line 623) - walking through looking for a PT_PAX_FLAGS header (lines 625-635) - updating flags when it finds one, returning failure if setting errors (~635-646), - returning success (651) ...It doesn't check for a PT_PAX_FLAGS header before calling set_pt_flags, nor does that function return an error if it never found one to update. This _might_ be intended behavior, but in that case the way pax-utils.eclass uses it is arguably wrong after all.
Hardened team, how should we proceed with the binary packages? Should we add a call to paxctl-ng -C before calling pax-mark in the ebuild?
