Summary: | sun-jdk: Simplification of PaX marking via pax-utils.eclass | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kevin F. Quinn (RETIRED) <kevquinn> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hardened, jkt |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Proposed patch using pax-utils to manipulate PaX flags
Patch for pax-utils.eclass Patch for pax-utils.eclass Updated ebuild diff - using list-paxables() |
Description
Kevin F. Quinn (RETIRED)
2006-11-24 07:09:25 UTC
Created attachment 102665 [details, diff]
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 attachment 103180 [details, diff]
Patch for pax-utils.eclass
My guess wold be that this is what you want.
Created attachment 103181 [details, diff]
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 attachment 103184 [details, diff]
Updated ebuild diff - using list-paxables()
(In reply to comment #9) > Created an attachment (id=103184) [edit] > 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 |