Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 613698 - sys-apps/elfix-0.9.2 "paxctl-ng -L foo" fails but returns success when foo has no PT_PAX_FLAGS header
Summary: sys-apps/elfix-0.9.2 "paxctl-ng -L foo" fails but returns success when foo ha...
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
Depends on:
Reported: 2017-03-23 23:48 UTC by Hank Leininger
Modified: 2017-05-26 06:29 UTC (History)
2 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Hank Leininger 2017-03-23 23:48:27 UTC
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

# 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

# paxctl-ng -v /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

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

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).
Comment 1 Hank Leininger 2017-03-23 23:55:35 UTC
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.
Comment 2 Tomáš Mózes 2017-05-26 06:29:24 UTC
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?