Dean Takemori: > Aha. I think I understand the issue now. =20 > > Loosely speaking, the PaX patch uses the compiler to prevent changes to=20= > > filesystem structures that "ought not" to be changed. On the other hand=20= > > aufs is by design not an ordinary filesystem and performes some "magic"=20= > > behind the scenes to make it appear ordinary to users. > > So the two projects are at odds in this area, and a code conflict is=20 > the result.
Exactly, basically. Also you may want to read past discussion between us via http://grsecurity.net/pipermail/grsecurity/2010-May/thread.html > The cleanest general solution I can see is if the PaX team would > accept some sort of CONFIG_PAX_CONSTIFY_FS_H kernel config option with = > some > appropriate ugliness=20 > > #ifdef CONFIG_PAX_CONSTIFY_FS_H > # define PAX_FS_H_CONST const > #else > # define PAX_FS_H_CONST > #endif ::: Hmm, I am afraid the PaX team may not agree, it looks a good idea. J. R. Okajima ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
