For example, firefox is supposed to have the m flag, but paxctl -v reports
- PaX flags: -------x-e-- [/nix/store/...-firefox-unwrapped-46.0.1/lib/firefox-46.0.1/firefox]
RANDEXEC is disabled
EMUTRAMP is disabled
Using paxctl directly works, however. I previously believed flags didn't work because ELF header markings are disabled in the default grsecurity config, but looks like they aren't applied at all.
Unsure how to debug this ... I'm fairly sure the problem is that the paxmark stub isn't being replaced by the one defined by paxctl's setup hook.
I'm tempted to replace uses of paxmark with
let # syntax highlighting
postFixup = ''
# ...
'' + optionalString stdenv.isLinux "paxctl -czexm $out/bin/foo";
which does work, per my testing.
I can confirm that deleting the dummy implementation of the paxmark function on
pkgs/stdenv/generic/setup.sh (here) flags are applied, so it isn't being overwritten by setup hook from paxctl package.
My experiments indicate that bash normally overwrites existing function definitions, I don't understand why that doesn't happen here. It looks like it _should_ work but doesn't ...
From reading setup.sh it seems clear the function is defined too late, after setup hooks are sourced. I wonder if this has ever worked...
@vcunat oh, so the stub actually overwrites the real function? IIRC, there have been no relevant changes after the paxmark mechanism was moved to the paxctl setup hook, so I think this may have been broken ever since.
It seems so; I was under the impression some people used this thing, but apparently not.
I've been slowly trying to get it into working shape, this is the only remaining stumbling block, that I know of. If you're right, the fix should be simple enough and we may finally get a working grsec desktop. Thanks.
@vcunat I have a fix ready at https://github.com/joachifm/nixpkgs/commit/54109fc52827384b4ee9702f72beaf8493413e6c, is it okay to pick it into staging or should I wait until libxml2 has completed (I suspect that is a smaller rebuild, so it makes sense for me to wait ...)
Wait for libxml2, please. It really is a significantly smaller rebuild, and more urgent (considering noone has noticed broken PaX for so long).
@vcunat it's okay to pick now, right?
Yes.
Most helpful comment
Wait for libxml2, please. It really is a significantly smaller rebuild, and more urgent (considering noone has noticed broken PaX for so long).