The installed sun-jdk is unuseable due to grsecurity restrictions. The ebuild must execute "paxctl -pemrxs <file>" on the following files in the jdk installation path: bin/jar bin/java bin/javac bin/javadoc jre/bin/java jre/bin/java_vm Without this users are unable to auto-update their systems (as the jdk installs and subsequently removes the old jdk, leaving the user without a working copy). Reproducible: Always Steps to Reproduce: 1. emerge sun-jdk 2. java/javac/etc. 3. Actual Results: Execution of any of the listed commands fails. Expected Results: Executed without problems. Applies to any grsecurity/hardened system with PaX enabled.
we use chpax for it if it's on the system. just emerge chpax and afterwards a jdk, then you're set
I already have chpax installed, and that didn't help: james root # rc-update -s default | grep chpax chpax | default james root # /etc/init.d/chpax status * status: started Seems like the chpax tool isn't detecting new packages then. I waited more than an hour and still the newly emerged javadoc wouldn't run. I had to manually run both chpax and paxctl (not sure which of them fixed it) on the packages as described previously.
Jan - the ebuilds fail to set the PaX flags for javadoc, both in the sun-jdk and the blackdown-jdk. Morten - currently /sbin/chpax is the only utility that works for foreign binaries, /sbin/paxctl is ineffective (but see bug #91122 if you're interested). However you're talking about /etc/init.d/chpax, the boot-time utility solar put together to set flags on boot across the system. It works, but you need to stop/start it after installing a package that needs it (this happens across a reboot, of course). /etc/init.d/chpax stop /etc/init.d/chpax start
fixed in cvs, now we call chpax also for the javadoc binary.
Thanks! (also to Kevin for the useful information bits)
