Stephen Smalley wrote:
On Sun, 2008-02-03 at 16:47 -0500, Joshua Brindle wrote:
Joshua Brindle wrote:
While testing the recent memory-related patches on a low memory machine
(512m total) I found that semodule still failed. It turns out that
fork() requires enough free ram for the amount of private dirty memory
in the parent process to succeed (even if it is never written to in the
child process). This patch moves the genhomedircon call to outside of
semanage_sandbox_install so that the policydb can be freed before any
forks happen. With this patch and the prior ones semodule runs fine on a
512m machine.
Signed-off-By: Joshua Brindle <method@xxxxxxxxxxxxxxx>
Interestingly this works sometimes and not others. I suppose it depends
on whether the libc allocator feels like giving up the memory when we
free the policydb or not. I am not sure what the best way to address
this is, any ideas?
First, slightly unrelated, am I correct that only your patch for
consuming base has been merged and not my two patches thus far? I'd
like to get those two merged before we do anything further. Should I
commit them? Looks like there is a minor conflict that I'll have to
resolve against your patch.
Yes, I didn't merge them, please go ahead and do so.
Second, have we considered dropping the separate execution of the
load_policy program and just directly invoking the libselinux function
for loading policy from libsemanage? Might require a policy change to
allow semodule to load policy directly.
We can, I don't think we are winning much by executing it separately.
Then there is the separate execution of setfiles -c to validate the file
contexts configuration against the policy. But that too could possibly
be replaced by direct calls to the relevant library functions.
We've encapsulated almost all of the load policy and setfiles logic in
libselinux these days, so it doesn't seem hard to eliminate the use of
separate helpers there. And since semodule is writing out the kernel
policy file that will be loaded, we aren't actually protecting against
anything by keeping load_policy in a separate domain (this is all under
direct method, of course).
Agreed. I am currently on vacation and probably won't get around to
doing this though.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
