From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
the SELinux folks are trying to introduce mprotect() API restrictions.
One variant of those restrictions is to not allow mprotect() on
A modified version of Roland McGrath's kernel patch to rhselinux-list
shows that X is mprotect()-ing what seems to be malloc() areas:
#2 X/2943: 0822f000-08232000 (00100077).
#2 X/2943: 08232000-0824a000 (00100073).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start X
Actual Results: X crashes.
Expected Results: X works fine.
The Xorg ELF loader is the culprit here. We enhanced the ELF loader
a year or two ago to call mprotect to flag memory regions with
PROT_EXEC in order for the X server to work with exec-shield.
The upstream X.Org project is currently planning on disabling the
ELF loader in X11R7, and using the dlopen loader instead, which
will have a nice side effect of resolving this issue, however
that wont likely be until the Fedora Core 5 / RHEL 5 timeframe.
If this feature request is intended for FC4 and/or RHEL4_Un updates,
we'll need to evaluate the ELF loader to determine how much effort
it might take to rework it to not require mprotect.
I've CC'd John Dennis, as I believe he did the mprotect
enhancements initially, and might be able to provide some useful
I'll bring this up on a future X devel team confcall to discuss
To be clear, it is perfectly fine to be using mprotect.
The issue is the use of mprotect on memory from malloc, sbrk, or static memory
regions such as big global arrays. That's what appears to be happening.
If the loader allocates memory with mmap and then uses mprotect on that, this
should not be a problem. Of course it can then just use the protection bits in
needs in the original mmap call.
I'm going on memory here with respect to how the code works, but I'm pretty sure
it does call mprotect on memory obtained from malloc. I'm not sure its worth
trying to rewrite the code if the X ELF loader can be replaced with dlopen. So
this might boil down to an issue of timing as to when the dlopen version the X
server is available.
Oh, almost forgot, its not just the X server which is setting execute permission
on memory. DRI and the OpenGL client library also does it.
This should all be resolved now with X11R7 in Fedora Core 5. If there
are any remaining issues, they should be reported in X.Org bugzilla and
Setting status to "RAWHIDE"
So, can somebody plase make sure the now unnecessary permissions are removed
from the SELinux policy?