Description of problem: The CFME installation crashes with ruby stack trace in appliance_console.log Version-Release number of selected component (if applicable): 5.6.2.2 How reproducible: always Steps to Reproduce: 1. Install RHEL7.2 and ensure that your version is later than Oct 20 (post dirty cow) 2. docker run --privileged -di cloud forms/cfme4:5.6.2.2 3. jump into the container 4. cloudforms never starts correctly 5. watch logs Actual results: cloudforms never starts correctly Expected results: cloudforms never starts correctly Additional info: To fix it: Run the following semanage command on the host semanage boolean --modify deny_execmem --off Stack Trace: /opt/rh/rh-ruby22/root/usr/share/gems/gems/ffi-1.9.8/lib/ffi/library.rb:263:in `attach': PJռ (RuntimeError) from /opt/rh/rh-ruby22/root/usr/share/gems/gems/ffi-1.9.8/lib/ffi/library.rb:263:in `attach_function' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/unix/uname.rb:29:in `<class:Uname>' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/unix/uname.rb:8:in `<module:Sys>' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/unix/uname.rb:6:in `<top (required)>' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/uname.rb:16:in `require_relative' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/uname.rb:16:in `<top (required)>' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys-uname.rb:1:in `require_relative' from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys-uname.rb:1:in `<top (required)>' from /opt/rh/rh-ruby22/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `require' from /opt/rh/rh-ruby22/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `rescue in require' from /opt/rh/rh-ruby22/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:39:in `require' from -e:1:in `<main>'
I suspect the ffi ruby library to trigger this. This lib is doing mmap PROT_READ calls which now may be block by deny_execmem In audit.log, I have: type=AVC msg=audit(1478684500.072:110316): avc: denied { execmem } for pid=115750 comm="ruby" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=process
Akram, Yes deny_execmem is something that was enabled on recent erratas, ffi seems to have routines to auto-detect selinux but they are probably not working properly inside containers since selinux would appear disabled. This issue is not limited to CFME, it will affect any application attempting to use ruby ffi inside containers. I wonder if this is something we can handle with docker-selinux.
I would prefer not to disable this for container types in general. Why not just disable the boolean.
Dan, It might be feasible to document and make users actually disable the boolean before attempting to run on docker hosts but this is problematic for Openshift users, as they have no control over the nodes or cluster in general and will prevent them from running unless the cluster admin grant the settings change cluster-wide or labels specially configured nodes for this type of deployments.
If this is actually a bug in selinux-policy update then OpenShift should make sure the boolean is turned off within its Ansible Playbooks.
Akram, I tested latest version on RHEL 7.2 (upgraded to the latest packages) used selinux-policy-3.13.1-102.el7_3.4 and # getsebool -a | grep deny_execmem deny_execmem --> off And succeeded running the latest docker image. Please specify what version of selinux/docker versions you are using.
Closing this bug as the info was not supplied. In case it comes up again please reopen.