Created attachment 338550 [details] Patch: Run paxmark -c on sqlpus in src_install For some reasons paxctl -c is sufficient. --- oracle-instantclient-sqlplus-11.2.0.3.ebuild 2012-11-15 21:01:06.000000000 +0100 +++ oracle-instantclient-sqlplus-11.2.0.3-r1.ebuild 2013-02-10 14:30:56.000000000 +0100 @@ -4,7 +4,7 @@ EAPI="4" -inherit eutils multilib +inherit eutils multilib pax-utils MY_PLAT_x86="Linux x86" MY_A_x86="${PN#oracle-}-linux-${PV}.0.zip" @@ -66,5 +66,7 @@ insinto "${oracle_home}"/sqlplus/admin doins glogin.sql + pax-mark -c "${ED}/${oracle_home}"/bin/sqlplus || die + dosym "${oracle_home}"/bin/sqlplus /usr/bin/sqlplus }
I'm not used to hardened, so: What is the problem here? Looking at the pax-utils.eclass makes me think that unconditionally using pax-mark() may lead to that "Executables may be killed by PaX kernels." warning on non-Linux architectures, or on non-hardened profiles when neither paxctl nor scanelf is available: PAX_MARKINGS defaults to !=none, but I fail to find any profile setting PAX_MARKINGS at all - I'm wondering if non-hardened profiles (or prefix profiles at least) should have PAX_MARKINGS=none.
(In reply to comment #1) > I'm not used to hardened, so: What is the problem here? I'm sorry, I should have documented it here. The problem is this: $ sqlplus sqlplus: error while loading shared libraries: libnnz11.so: cannot enable executable stack as shared object requires: Permission denied > Looking at the pax-utils.eclass makes me think that unconditionally using > pax-mark() may lead to that "Executables may be killed by PaX kernels." > warning on non-Linux architectures, or on non-hardened profiles when neither > paxctl nor scanelf is available: PAX_MARKINGS defaults to !=none, but I fail > to find any profile setting PAX_MARKINGS at all - I'm wondering if > non-hardened profiles (or prefix profiles at least) should have > PAX_MARKINGS=none. I'd think PAX_MARKINGS should be set within the hardened profile only and left unset otherwise. pax-utils.eclass should abstain from setting a default value. When I created the patch, I was convinced "pax-mark" would not do anything outside of the hardened environment. Now, when loooking closer at what the eclass really does, I recognize that this was an overly optimistic assumption. /usr/portage/eclass/pax-utils.eclass (as installed by portage-2.1.11.51): 1.) PAX_MARKINGS=${PAX_MARKINGS:="PT"} 2.) if type -p paxctl > /dev/null && has PT ${PAX_MARKINGS}; then 3.) elif type -p scanelf > /dev/null && [[ ${PAX_MARKINGS} != "none" ]]; then So if PAX_MARKINGS was previously unset, "has PT" is always true and consequently PAX_MARKING is also unequal to "none", with scanelf always being installed. $ grep -R PAX_MARKINGS /usr/portage/profiles/ does not find anything. Here is what I get when I put trace statements around PAX_MARKINGS=${PAX_MARKINGS:="PT"}: PAX_MARKINGS before set default: '' PAX_MARKINGS after set default: 'PT' The package manager specification (app-doc/pms-5) does not say anything about harden.* or pax.*
(In reply to comment #2) > $ sqlplus > sqlplus: error while loading shared libraries: libnnz11.so: cannot enable > executable stack as shared object requires: Permission denied Let me understand what's going on here: Besides being the first sharedlib to be loaded for sqlplus (due to deep DT_NEEDED deps), libnnz11.so does have some flag set indicating it requires an executable stack. Now the sqlplus executable also needs some flag to be set to tell the kernel to allow for an executable stack in this process. Right so far? Which kind of flag does 'paxctl -c' actually set into the binary? Question now is: Does libnnz11.so really /need/ an executable stack, or is it just the flag being set in the sharedlib?
(In reply to comment #3) > (In reply to comment #2) > Let me understand what's going on here: > Besides being the first sharedlib to be loaded for sqlplus (due to deep > DT_NEEDED deps), libnnz11.so does have some flag set indicating it requires > an executable stack. > Now the sqlplus executable also needs some flag to be set to tell the kernel > to allow for an executable stack in this process. Right so far? As I understand it, the library tries to mmap memory segments with write and exec flags set at the same time. Often this is only due to careless programming and actually not really needed, which is why pax recently startet to silently demote such requests to r-x. But I doubt that the error message reflects the real cause. > Which kind of flag does 'paxctl -c' actually set into the binary? It adds a PT_PAX_FLAGS header with no explicit flags set, and this leaves the system default pax flags active. However, while this works I still do not understand why it is needed at all. Here is the output of scanelf on sqlplus before paxctl -c was applied: # scanelf -a /usr/bin/sqlplus TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE ET_EXEC PeMRxS 0755 LE RW- --- RW- - /ade/aime_sqlplus_12363/oracle/lib LAZY /usr/bin/sqlplus Type is ET_EXEC! I thought PAX does not care about ET_EXEC type files? And note the PAX flags... (well, also note rpath -- but this is a different story) I feel like I had to prove that I'm really using the the unmodified file: # sqlplus sqlplus: error while loading shared libraries: libnnz11.so: cannot enable executable stack as shared object requires: Permission denied Ok. # paxctl -v /usr/bin/sqlplus file /usr/bin/sqlplus does not have a PT_PAX_FLAGS program header, try conversion # paxctl -cv /usr/bin/sqlplus file /usr/bin/sqlplus had a PT_GNU_STACK program header, converted - PaX flags: -------x-e-- [/usr/bin/sqlplus] RANDEXEC is disabled EMUTRAMP is disabled # scanelf -a /usr/bin/sqlplus TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE ET_EXEC ---xe- 0755 LE --- --- RW- - /ade/aime_sqlplus_12363/oracle/lib LAZY /usr/bin/sqlplus > Question now is: > Does libnnz11.so really /need/ an executable stack, > or is it just the flag being set in the sharedlib? Before I opened this bug I've also tried this, for the sake of completness. It did not changed anything noticeable. I remember to have read somewhere that the pax flags must be set on the first ET_DYN object to become effective. But sqlplus is of type ET_EXEC.
Fixed in oracle-instantclient-sqlplus-11.2.0.3-r1, thank you!
