GIMP help shouldn't need execstack, should it?

[Göran Uddeborg]

I discovered recently that gimp help crashes with a segmentation fault
and an execmem AVC denial.  I could make it work either by setting
allow_execstack to on, or by changing the type of
/usr/lib64/gimp/2.0/plug-ins/help-browser to
unconfined_execmem_exec_t.

I assume this is a bug in the help-browser that I should report.  My
understanding is that execstack should not be needed.  But before I do
I thought I check with the knowledgable people here.  Is this AVC
denial a result of an application bug, or could it be valid for gimp
help to request this?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2011 11:49 PM, Göran Uddeborg wrote:
>  I discovered recently that gimp help crashes with a segmentation
> fault
>  and an execmem AVC denial.  I could make it work either by setting
>  allow_execstack to on, or by changing the type of
>  /usr/lib64/gimp/2.0/plug-ins/help-browser to
>  unconfined_execmem_exec_t. 
see if it works when you remove the execstack flag from help-browser
(man execstack)

But in general i believe execstack should most of the time not be needed
in Linux

>  I assume this is a bug in the help-browser that I should report.  My
>  understanding is that execstack should not be needed.  But before I do
>  I thought I check with the knowledgable people here.  Is this AVC
>  denial a result of an application bug, or could it be valid for gimp
>  help to request this?
>  
>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0nHx0ACgkQMlxVo39jgT8DwACffPV7SUh89Jg67i+fpnDtIkG/
> QRAAn1Z710R2xL2//pj7FD++xMhH4lCR
> =2YLt
> -----END PGP SIGNATURE-----

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 09:11 AM, Dominick Grift wrote:
>  On 01/06/2011 11:49 PM, Göran Uddeborg wrote:
> > I discovered recently that gimp help crashes with a segmentation fault
> > and an execmem AVC denial.  I could make it work either by setting
> > allow_execstack to on, or by changing the type of
> > /usr/lib64/gimp/2.0/plug-ins/help-browser to
> > unconfined_execmem_exec_t.
>  
>  see if it works when you remove the execstack flag from help-browser
>  (man execstack)
>  
>  But in general i believe execstack should most of the time not be needed
>  in Linux
>  
> > I assume this is a bug in the help-browser that I should report.  My
> > understanding is that execstack should not be needed.  But before I do
> > I thought I check with the knowledgable people here.  Is this AVC
> > denial a result of an application bug, or could it be valid for gimp
> > help to request this?
>  
>  
>  
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
- --
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

We have had a slew of bugzillas on this lately.  I think some libraries
in rpmfusion or one of the other Not Fully Open, yum repositories have
some libraries that are marked as requiring execstack.

We have been closing these with a link to this bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=652297#c5

I have hard coded my comment in it on how to look for the libraries.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0nMGsACgkQrlYvE4MpobOtowCg00lNOyWUxFnyTx7WK4cqgLXe
> qwAAn3jNe499cHb40gqaoD7fh2S1ukqb
> =PykE
> -----END PGP SIGNATURE-----

[Gregory Maxwell]

On Fri, Jan 7, 2011 at 10:25 AM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  We have had a slew of bugzillas on this lately.  I think some
> libraries
>  in rpmfusion or one of the other Not Fully Open, yum repositories have
>  some libraries that are marked as requiring execstack.
>
>  We have been closing these with a link to this bugzilla.
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=652297#c5
>
>  I have hard coded my comment in it on how to look for the libraries. 
Perhaps RPM/Yum should be modified to refuse to install libraries set
to execstack this without some kind of override, or at least a nasty
warning. "Warning: Package FOO compromises system security. See here
for more information:"

This is a usability problem and it needs to be resolved but it is not
going to be resolved by closing dozens of bugs and telling people to
"setsebool -P allow_execstack 1", nor is resolving the usability
problem by disabling the non-executable stack in the default install
acceptable.

This is especially bad in that some of the triggering libraries are
media codecs which get exposed to potentially hostile files from third
parties.

[John Reiser]

https://bugzilla.redhat.com/show_bug.cgi?id=652297#c66

The package maintainer can turn off execstack when linking the app by adding
"-Wl,-z,noexecstack" to the LDFLAGS (or CFLAGS) in the Makefile.  This takes
precedence over .o files or libraries that request execstack, either
deliberately or because some .S assembly language file forgot to use ".section
.note.GNU-stack,"",@progbits" where the empty attribute string ""
turns off
execstack.

--

[Göran Uddeborg]

Dominick Grift:
>  see if it works when you remove the execstack flag from help-browser
>  (man execstack) 
It turns out the help-browser does not have any execstack flag set.
And none of the libraries involved either.

I used strace to see what actually was done, and found out that this
happens when the process tries to mmap() some anonymous memory:

    17020 gettimeofday( <unfinished ...>
    17020 <... gettimeofday resumed> {1294488756, 742289}, NULL) = 0
    17020 mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
    17020 <... mmap resumed> )              = -1 EACCES (Permission denied)
    17020 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

Looking a bit more (and repeating how to debug applications that fork
with gdb:-) I found that this is in the
/usr/lib64/libwebkitgtk-1.0.so.0, with the stack trace included below.

I don't know anything about webkitgtk, but strings such as "jit" in
that trace make me suspect that maybe this could be intentional.  Now
I'm not sure what to do.  Should I bug report webkitgtk.  And if so,
is there any "right" way to do just-in-time compilation, if that is
indeed what happens?  Any good pointers I could add to such a bug
report?

(gdb) bt
#0  0x00007f32c379ab13 in FixedVMPoolAllocator (this=<value optimized out>) at
JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:308
#1  JSC::ExecutableAllocator::isValid (this=<value optimized out>) at
JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:460
#2  0x00007f32c3706e8d in ExecutableAllocator (this=0x7f32c5243a00,
globalDataType=<value optimized out>, threadStackType=JSC::ThreadStackTypeLarge) at
JavaScriptCore/jit/ExecutableAllocator.h:176
#3  JSC::JSGlobalData::JSGlobalData (this=0x7f32c5243a00, globalDataType=<value
optimized out>, threadStackType=JSC::ThreadStackTypeLarge) at
JavaScriptCore/runtime/JSGlobalData.cpp:150
#4  0x00007f32c3707883 in JSC::JSGlobalData::create (type=JSC::ThreadStackTypeLarge) at
JavaScriptCore/runtime/JSGlobalData.cpp:239
#5  0x00007f32c37078d2 in JSC::JSGlobalData::createLeaked (type=JSC::ThreadStackTypeLarge)
at JavaScriptCore/runtime/JSGlobalData.cpp:245
#6  0x00007f32c28f16c2 in WebCore::JSDOMWindowBase::commonJSGlobalData () at
WebCore/bindings/js/JSDOMWindowBase.cpp:165
#7  0x00007f32c2942d8c in WebCore::ScriptController::getAllWorlds (worlds=...) at
WebCore/bindings/js/ScriptController.cpp:181
#8  0x00007f32c2caf7f2 in WebCore::FrameLoader::dispatchDidClearWindowObjectsInAllWorlds
(this=0x7f32c5208458) at WebCore/loader/FrameLoader.cpp:3347
#9  0x00007f32c2cafa62 in WebCore::FrameLoader::receivedFirstData (this=0x7f32c5208458) at
WebCore/loader/FrameLoader.cpp:617
#10 0x00007f32c2ca8eb8 in WebCore::DocumentWriter::setEncoding (this=<value optimized
out>, name=..., userChosen=false) at WebCore/loader/DocumentWriter.cpp:236
#11 0x00007f32c2c9cd26 in WebCore::DocumentLoader::commitData (this=0x7f32c520b800,
bytes=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
Transitional//EN\"
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www"..., length=8192) at WebCore/loader/DocumentLoader.cpp:305
#12 0x00007f32c30c93c5 in WebKit::FrameLoaderClient::committedLoad (this=0x7f32c51f7b40,
loader=0x7f32c520b800, data=0x1860190 "<?xml version=\"1.0\"
encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE html PUBLIC
\"-//W3C//DTD XHTML 1.0 Transitional//EN\"
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www"..., length=8192) at
WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:253
#13 0x00007f32c2c9dc06 in WebCore::DocumentLoader::commitLoad (this=0x7f32c520b800,
data=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
Transitional//EN\"
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www"..., length=8192) at WebCore/loader/DocumentLoader.cpp:292
#14 0x00007f32c2ced7c1 in WebCore::ResourceLoader::didReceiveData (this=0x7f32c5238680,
data=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
Transitional//EN\"
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www"..., length=8192, lengthReceived=8192, allAtOnce=<value
optimized out>) at WebCore/loader/ResourceLoader.cpp:262
#15 0x00007f32c2cda015 in WebCore::MainResourceLoader::didReceiveData
(this=0x7f32c5238680, data=0x1860190 "<?xml version=\"1.0\"
encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE html PUBLIC
\"-//W3C//DTD XHTML 1.0 Transitional//EN\"
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www"..., length=8192, lengthReceived=8192, allAtOnce=false) at
WebCore/loader/MainResourceLoader.cpp:435
#16 0x00007f32c2cebcfa in WebCore::ResourceLoader::didReceiveData (this=0x7f32c5238680,
data=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
Transitional//EN\"
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www"..., length=8192, lengthReceived=<value optimized out>)
at WebCore/loader/ResourceLoader.cpp:415
#17 0x00007f32c30a5b3a in WebCore::readCallback (source=<value optimized out>,
asyncResult=0x1846aa0, data=0x0) at
WebCore/platform/network/soup/ResourceHandleSoup.cpp:818
#18 0x00007f32bff90579 in ?? () from /lib64/libgio-2.0.so.0
#19 0x00007f32bff9f258 in ?? () from /lib64/libgio-2.0.so.0
#20 0x00007f32bf41ce33 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#21 0x00007f32bf41d610 in ?? () from /lib64/libglib-2.0.so.0
#22 0x00007f32bf41dc82 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#23 0x00007f32c1f970b7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#24 0x0000000000406f85 in run (name=<value optimized out>, nparams=5,
param=0x154f8f0, nreturn_vals=<value optimized out>, return_vals=<value optimized
out>) at help-browser.c:163
#25 0x00007f32c4cd4ae6 in gimp_proc_run (info=<value optimized out>, argc=<value
optimized out>, argv=<value optimized out>) at gimp.c:1917
#26 gimp_loop (info=<value optimized out>, argc=<value optimized out>,
argv=<value optimized out>) at gimp.c:1751
#27 gimp_main (info=<value optimized out>, argc=<value optimized out>,
argv=<value optimized out>) at gimp.c:487
#28 0x00007f32bee38e7d in __libc_start_main () from /lib64/libc.so.6
#29 0x0000000000406099 in _start ()

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2011 01:50 PM, Göran Uddeborg wrote:
>  Dominick Grift:
> > see if it works when you remove the execstack flag from help-browser
> > (man execstack)
>  
>  It turns out the help-browser does not have any execstack flag set.
>  And none of the libraries involved either.
>  
>  I used strace to see what actually was done, and found out that this
>  happens when the process tries to mmap() some anonymous memory:
>  
>      17020 gettimeofday( <unfinished ...>
>      17020 <... gettimeofday resumed> {1294488756, 742289}, NULL) = 0
>      17020 mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
>      17020 <... mmap resumed> )              = -1 EACCES (Permission denied)
>      17020 --- SIGSEGV (Segmentation fault) @ 0 (0) --- 
I guess you have to label help-browser execmem_exec_t then.

>  Looking a bit more (and repeating how to debug applications that
> fork
>  with gdb:-) I found that this is in the
>  /usr/lib64/libwebkitgtk-1.0.so.0, with the stack trace included below.
>  
>  I don't know anything about webkitgtk, but strings such as "jit" in
>  that trace make me suspect that maybe this could be intentional.  Now
>  I'm not sure what to do.  Should I bug report webkitgtk.  And if so,
>  is there any "right" way to do just-in-time compilation, if that is
>  indeed what happens?  Any good pointers I could add to such a bug
>  report? 
JIT indeed is know to atleast "execmem", but i am not sure if the same
applies to "execstack"

I think that help-browser needs to be labelled execmem_exec_t, see if
that works for you.

If it does then consider reporting it to selinux-policy so that a file
context specification can be added to the execmem module.

In other words:

1. i think help-browser needs "execmem" because of the JIT compiler.
2. i am not sure if it actually need "execstack". (unless you show me an
AVC denial proving that it needs "execstack".
3. i think labelling help-browser type execmem_exec_t might fix this issue.
4. i think JIT compilers generally need execmem, and that this from that
perspective is not a bug.

>  
>  (gdb) bt
>  #0  0x00007f32c379ab13 in FixedVMPoolAllocator (this=<value optimized out>) at
> JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:308
>  #1  JSC::ExecutableAllocator::isValid (this=<value optimized out>) at
> JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:460
>  #2  0x00007f32c3706e8d in ExecutableAllocator (this=0x7f32c5243a00,
> globalDataType=<value optimized out>, threadStackType=JSC::ThreadStackTypeLarge) at
> JavaScriptCore/jit/ExecutableAllocator.h:176
>  #3  JSC::JSGlobalData::JSGlobalData (this=0x7f32c5243a00, globalDataType=<value
> optimized out>, threadStackType=JSC::ThreadStackTypeLarge) at
> JavaScriptCore/runtime/JSGlobalData.cpp:150
>  #4  0x00007f32c3707883 in JSC::JSGlobalData::create (type=JSC::ThreadStackTypeLarge) at
> JavaScriptCore/runtime/JSGlobalData.cpp:239
>  #5  0x00007f32c37078d2 in JSC::JSGlobalData::createLeaked
> (type=JSC::ThreadStackTypeLarge) at JavaScriptCore/runtime/JSGlobalData.cpp:245
>  #6  0x00007f32c28f16c2 in WebCore::JSDOMWindowBase::commonJSGlobalData () at
> WebCore/bindings/js/JSDOMWindowBase.cpp:165
>  #7  0x00007f32c2942d8c in WebCore::ScriptController::getAllWorlds (worlds=...) at
> WebCore/bindings/js/ScriptController.cpp:181
>  #8  0x00007f32c2caf7f2 in WebCore::FrameLoader::dispatchDidClearWindowObjectsInAllWorlds
> (this=0x7f32c5208458) at WebCore/loader/FrameLoader.cpp:3347
>  #9  0x00007f32c2cafa62 in WebCore::FrameLoader::receivedFirstData (this=0x7f32c5208458)
> at WebCore/loader/FrameLoader.cpp:617
>  #10 0x00007f32c2ca8eb8 in WebCore::DocumentWriter::setEncoding (this=<value optimized
> out>, name=..., userChosen=false) at WebCore/loader/DocumentWriter.cpp:236
>  #11 0x00007f32c2c9cd26 in WebCore::DocumentLoader::commitData (this=0x7f32c520b800,
> bytes=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
> standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
> Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
> xmlns=\"http://www"..., length=8192) at WebCore/loader/DocumentLoader.cpp:305
>  #12 0x00007f32c30c93c5 in WebKit::FrameLoaderClient::committedLoad (this=0x7f32c51f7b40,
> loader=0x7f32c520b800, data=0x1860190 "<?xml version=\"1.0\"
> encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE html PUBLIC
> \"-//W3C//DTD XHTML 1.0 Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
> xmlns=\"http://www"..., length=8192) at
> WebKit/gtk/WebCoreSupport/FrameLoaderClientGtk.cpp:253
>  #13 0x00007f32c2c9dc06 in WebCore::DocumentLoader::commitLoad (this=0x7f32c520b800,
> data=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
> standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
> Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
> xmlns=\"http://www"..., length=8192) at WebCore/loader/DocumentLoader.cpp:292
>  #14 0x00007f32c2ced7c1 in WebCore::ResourceLoader::didReceiveData (this=0x7f32c5238680,
> data=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
> standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
> Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
> xmlns=\"http://www"..., length=8192, lengthReceived=8192, allAtOnce=<value
> optimized out>) at WebCore/loader/ResourceLoader.cpp:262
>  #15 0x00007f32c2cda015 in WebCore::MainResourceLoader::didReceiveData
> (this=0x7f32c5238680, data=0x1860190 "<?xml version=\"1.0\"
> encoding=\"UTF-8\" standalone=\"no\"?>\n<!DOCTYPE html PUBLIC
> \"-//W3C//DTD XHTML 1.0 Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
> xmlns=\"http://www"..., length=8192, lengthReceived=8192, allAtOnce=false) at
> WebCore/loader/MainResourceLoader.cpp:435
>  #16 0x00007f32c2cebcfa in WebCore::ResourceLoader::didReceiveData (this=0x7f32c5238680,
> data=0x1860190 "<?xml version=\"1.0\" encoding=\"UTF-8\"
> standalone=\"no\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
> Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
> xmlns=\"http://www"..., length=8192, lengthReceived=<value optimized out>)
> at WebCore/loader/ResourceLoader.cpp:415
>  #17 0x00007f32c30a5b3a in WebCore::readCallback (source=<value optimized out>,
> asyncResult=0x1846aa0, data=0x0) at
> WebCore/platform/network/soup/ResourceHandleSoup.cpp:818
>  #18 0x00007f32bff90579 in ?? () from /lib64/libgio-2.0.so.0
>  #19 0x00007f32bff9f258 in ?? () from /lib64/libgio-2.0.so.0
>  #20 0x00007f32bf41ce33 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
>  #21 0x00007f32bf41d610 in ?? () from /lib64/libglib-2.0.so.0
>  #22 0x00007f32bf41dc82 in g_main_loop_run () from /lib64/libglib-2.0.so.0
>  #23 0x00007f32c1f970b7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
>  #24 0x0000000000406f85 in run (name=<value optimized out>, nparams=5,
> param=0x154f8f0, nreturn_vals=<value optimized out>, return_vals=<value optimized
> out>) at help-browser.c:163
>  #25 0x00007f32c4cd4ae6 in gimp_proc_run (info=<value optimized out>, argc=<value
> optimized out>, argv=<value optimized out>) at gimp.c:1917
>  #26 gimp_loop (info=<value optimized out>, argc=<value optimized out>,
> argv=<value optimized out>) at gimp.c:1751
>  #27 gimp_main (info=<value optimized out>, argc=<value optimized out>,
> argv=<value optimized out>) at gimp.c:487
>  #28 0x00007f32bee38e7d in __libc_start_main () from /lib64/libc.so.6
>  #29 0x0000000000406099 in _start () 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0oX6cACgkQMlxVo39jgT+1ZwCgoYH/g5vGMWuN9ywvra5DWQj2
> m/sAn2c/kg9GQl3njiYpmctoj6PPADR9
> =+9w4
> -----END PGP SIGNATURE-----

[Göran Uddeborg]

Dominick Grift:
>  JIT indeed is know to atleast "execmem", but i am not sure
> if the same
>  applies to "execstack" 
It appears not.  My inital guesses about execstack seems to have been
wrong.  But for some reason, enabling alllow_execstack ALSO makes the
help browser work.

>  I think that help-browser needs to be labelled execmem_exec_t, see
> if
>  that works for you. 
It does.

>  If it does then consider reporting it to selinux-policy 
Done: https://bugzilla.redhat.com/show_bug.cgi?id=668162

>  4. i think JIT compilers generally need execmem, and that this from
> that
>  perspective is not a bug. 
Understood.  I guess any using webkitgtk could need it then.  But
there isn't any way to enable it for all using the library, but just
inside the library, is there?

[John Reiser]

On 01/08/2011 04:50 AM, Göran Uddeborg wrote:
>  It turns out the help-browser does not have any execstack flag set.
>  And none of the libraries involved either.
>  
>  I used strace to see what actually was done, and found out that this
>  happens when the process tries to mmap() some anonymous memory:
>  
>      17020 gettimeofday( <unfinished ...>
>      17020 <... gettimeofday resumed> {1294488756, 742289}, NULL) = 0
>      17020 mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
>      17020 <... mmap resumed> )              = -1 EACCES (Permission denied)
>      17020 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>  
>  Looking a bit more (and repeating how to debug applications that fork
>  with gdb:-) I found that this is in the
>  /usr/lib64/libwebkitgtk-1.0.so.0, with the stack trace included below.
>  
>  I don't know anything about webkitgtk, but strings such as "jit" in
>  that trace make me suspect that maybe this could be intentional.  Now
>  I'm not sure what to do.  Should I bug report webkitgtk. 
Yes, file a bug against webkitgtk.  Include the output from strace.

>    And if so,
>  is there any "right" way to do just-in-time compilation, if that is
>  indeed what happens?  Any good pointers I could add to such a bug
>  report? 
This works for me: allocate space first as PROT_NONE, then MAP_FIXED the
allocated space to the desired protection:

    addr = mmap(0,    length, PROT_NONE, MAP_PRIVATE_MAP_ANONYMOUS, -1, 0);
    if (MAP_FAILED==addr) ...
    addr = mmap(addr, length, PROT_READ|PROT_WRITE|PROT_EXEC,
        MAP_FIXED|MAP_PRIVATE_MAP_ANONYMOUS, -1, 0);
    if (MAP_FAILED==addr) ...

--