Bugzilla Bug 156135

Hi.  I've added to portage an eclass (eutil, really) that provides functions to
manipulate PaX flags on executables.  The eclass manages the use of the various
PaX flag manipulation programs that may or may not be present on the build
system, so that as these tools develop we can just modify the eclass without
nagging all the affected packages.

To follow; a patch for the sun-jdk-1.5.0.09-r1 ebuild, for your perusal.  I've
put the call at the start of src_install() instead of post_install(), so that
the checksums recorded by portage in its database agree with what is on the
filesystem.  If you're happy with that patch, let me know and I'll commit it
and similar across all the jdk/jre packages (if you don't want me to touch
anything I'll supply patches for them all here).

Created an attachment (id=102665) [details]
Proposed patch using pax-utils to manipulate PaX flags

Also worth noting is that the chpax method for PaX flags (currently used by the
ebuilds) is slowly being deprecated.

The patch certainly does clean things up. Perhaps the eclass could use a helper
method for finding which should be tweaked? ie, something that would
effectively do:
file ${S}/bin/* ${S}/jre/bin/* | grep ELF | sed -e 's/:.*$//'

Sounds useful - something like:

list-paxables() {
    file $* 2> /dev/null | grep ELF | sed -e 's/:.*$//'
}

so you could have:

    pax-mark m $(list-paxables ${S}/{jre/}bin)

I shy away from using a 'find', as ideally each ebuild should know exactly
which files need the markings, and where they are.   In this case such a list
would be tedious, and I'm pretty sure most if not all the jdk/jre executables
use java themselves.

That usage looks great to me.

Tested this on my hardened server and the eclass or the usage in the ebuild is
buggy:

/usr/portage//eclass/pax-utils.eclass: line 26:  
/var/tmp/portage/sun-jdk-1.5.0.10/work/jdk1.5.0_10/bin/appletviewer: No such
file or directory

Created an attachment (id=103180) [details]
Patch for pax-utils.eclass

My guess wold be that this is what you want.

Created an attachment (id=103181) [details]
Patch for pax-utils.eclass

My guess wold be that this is what you want.

Yes; sorry - had it fixed locally but not committed to CVS.

Created an attachment (id=103184) [details]
Updated ebuild diff - using list-paxables()

(In reply to comment #9)
> Created an attachment (id=103184) [edit] [details]
> Updated ebuild diff - using list-paxables()
> 

Yeah seems to work. Feel free to add the other VMs that need it. You can get
that by checking the ebuilds that inherit java-vm* eclasses. Should also add
the every slot of them. ;D sun-jdk and sun-jre-bin 1.5 are taken care off.

Quick q - just did blackdown-jdk but didn't do a rev-bump as I figured anyone
who already has it installed and working doesn't need to re-emerge.  Would you
prefer a rev-bump?

I think it's fine without a revbump.

(In reply to comment #12)
> I think it's fine without a revbump.
> 

It's fine without a revbump for ~arch. I prefer to have revision bumps if there
are only stable versions as stable versions should never be modified directly.

Seems to have already been committed