I don't see this issue.

Could you provide a machine where it happens?

I believe Gilles is able to provide you the machine.

Only reason I could see for this would be if there was limited memory on the system.  setsebool and semanage commands use a lot of memory to compile policy

Hi Daniel,

(In reply to Daniel Walsh from comment #4)
> Only reason I could see for this would be if there was limited memory on the
> system.  

That makes sense and will explain why the issue is not happening consistently,
I was starting to suspect a memory issue.

In the case of deploying an All-in-one OpenStack scenario the machine is under heavy load of services. My initial test case was using a VM with 2048MB of RAM, which I doubled up later!

>setsebool and semanage commands use a lot of memory to compile
> policy

Do there is an option/way to extend the timeout kill?

Thanks

No sorry.

What could be done is running setsebool before starting all the services we start and probably setting vm.min_free_kbytes = 45056 might help woth oomkill :/

(In reply to Lukas Bezdicka from comment #7)
> What could be done is running setsebool before starting all the services we
> start and probably setting vm.min_free_kbytes = 45056 might help woth
> oomkill :/

That's a good idea. 
But I'm not sure if that's going to make an overall impact because every individual service is managed atomically (package, configuration and service).

I wonder if there is any way to pre-compile policies before hand in order to alleviate the process when setsebool is executed.

Created attachment 897992 [details]
libsepol valgrind happy

(In reply to Lukas Bezdicka from comment #9)
> Created attachment 897992 [details]
> libsepol valgrind happy

One thing, that might not be related but potentially bad, see lines 1460/1461:
------
if (linear_probe_create(&probe, 4096)) { /* Assume 4096 is enough for most cases */
------

Anyway, the question remains: 
Why is this happening at all?
Compiling time is inversely proportional to available resources.
Less memory usually translates to more process time but not a failure.

Created attachment 898647 [details]
massif output of setsebol

Hi Lukas,

That looks good but can you please comment your attachments and more specifically this massive output.

Thanks,
Gilles

Well the first patch is useless as the upstream dropped whole linear_probe patch (see e910cf6e62d94d09e810bd173c14c5c4afb72242). As for the massif output it's clear that issue is in semanage_link_sandbox(). I tried two different approaches one would be loading module, linking it and clearing it out, but link_modules() function seems to be too complex for me and I don't think it can be changed in this way without major refactor. The other approach was to try to store only required data from module but there I got lost in all the pointers in mod_pols in sepol_link_packages(). This is probably for someone more experienced with the selinux userspace code.

Let's see if we have SELINUX resource available to help confirm there's nothing much we could do on our side and see how to work that upstream.

I am running F20 in a kvm/qemu virtual machine with 2 cores and 2GB RAM.  Both setsebool and semanage boolean run OOM trying to set httpd_can_network_connect.

If I increase the RAM in the VM to 4GB, it works.  So at least there is a workaround.

(In reply to Rich Megginson from comment #15)

> If I increase the RAM in the VM to 4GB, it works.  So at least there is a
> workaround.

No sure if that's a workaround for everyone ;-)

Created attachment 921017 [details]
Skip policy module re-linking when only setting a boolean

(In reply to Stephen Smalley from comment #17)
> Created attachment 921017 [details]
> Skip policy module re-linking when only setting a boolean

I confirm that with patch setsebool -P httpd_can_network_connect takes shorter time and does take about ~400MB which is much better.

~400MB?  In my testing, valgrind --tool=massif setsebool -P httpd_can_network_connect=1 peaks at 26.97MB with this patch.  On Fedora 20.

Oh yes, I was testing purely the patch on clean source, the redhat patch in libsemanage package does the magic. 28mb now.

I can confirm it too.

That's great! 
Bravo to Stephen.
Thank you everyone for helping/testing.

Hi,

Has an updated package been released? I still see this problem on an up-to-date CentOS 7 image with 1024M RAM (it's a VM on a resource-constrained machine).

Thank,s
Dave.

*** Bug 1080481 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2148.html

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days