Summary: | sys-apps/elfix-0.9.2 "paxctl-ng -L foo" fails but returns success when foo has no PT_PAX_FLAGS header | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hank Leininger <hlein> |
Component: | Current packages | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | blueness, hydrapolic |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Hank Leininger
2017-03-23 23:48:27 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. 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? |