On Wed, 4 May 2005, Pedro Venda wrote: > > Now I know for a fact that this lib can be built without text > > relocations. It's often the conversion process for normal users that > > come from non hardened envionments to a hardened one that have this > > problem. It's usually caused by a non pic aware libcrypto.a that gets > > used to later link to the libphp4.so > > so the hardened toolchain could rebuild the offending library and link the > module against the pic object, resulting in a working combo?
gcc should be rebuilt w/ hardened so that the system defaults to PIE executables (ET_DYN), not ET_EXEC adding also SSP protection. I had trouble myself w/ the php module and php itself (the shared lib) having text relocations, the only solution for any corner case (also working w/ uclibc) is to add --with-pic to econf (in ebuild). This is true for a hardened system, any other proposed solution will break here and there. > > I really recommended -e world (lot of other cases where non-pic > > something.a gets mis linked in) I would propose before running emerge -e world to: a. use a hardened profile (or add hardened pic USE) b. rebuild gcc, binutils, gcc, glibc, gcc (in this order) > > but the use flags hardened and pic seldom appear. I suppose that the flag is > not really necessary to build PIC code. the toolchain will do that for me. gcc will change defaults as stated earlier > is the flag there for known workarounds? no Peter -- Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 -- [email protected] mailing list
