Almost all ebuilds that call pax-mark() do so in the install() phase. That's OK for marks in ELF headers, but xattr-based marking is enabled globally now (and is to become the only way soon, if I'm deducing correctly) and a problem may arise from the fs not supporting xattrs. When the target fs for a pkg's files doesn't support xattrs, it's a game over scenario, that's for sure. But when it does support xattrs, but TMPDIR does not, the game can still be won if ebuilds call pax-mark() in postinst(). That way, the user can still get properly marked binaries, while not having to have xattr support in TMPDIR. There are dozens of packages that use PaX markings for their binaries. Opening a bug for each one of them, requesting the move of pax-mark() from install() to postinst(), may not be a good idea. (Please, let me know if you don't think so.) So I'm proposing that at least a note for ebuild authors be added to the devmanual (pax-utils.eclass page, probably) about the advantage of calling pax-mark() in postinst(). Reproducible: Always
pax marks are needed for tests very often, so this is not an option. the marks are applied before we need them, it cannot be done in postinst. If you want to run a hardened system in the future your choices will be either don't use anything that needs paxmarks, or have a filesystem with xattr.
