I've been trying to track down an annoying bug with SELinux these days.

The situation is as follows: when I'm running enforcing mode, binds' "host" command, "named" itself and "dig" won't work. They fail with an odd error message:

mem.c:653: INSIST(ctx->stats[size].gets > 0U) failed.

or with the latest bind backported to stable:

host: isc_taskmgr_create: no available threads

the SELinux audit error reported is denied { execmem } for pid=28566 comm="host" scontext=root:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t tclass=process.

As far as I know, "execmem" means the process can do runtime code generation (i.e. make its own memory executable) - that is a privilege you don't want to give out lightly. But everybody should be able to use the "host" command... so the situation sucks.

Right now I guess that this is caused by pthreads, not bind itself.

Anyone some hints for me? Does this mean I have to build a customized libc to run stable with SELinux (or make huge modifications to the policy, to add a domain for "host" and exec permissions to every other domain that needs to be able to run "host"...)?

Dear Lazyweb,
Nothing is perfect, but on Linux you can at least improve it and tune it.

I just ran into memory problems on my development box - I had tons of applications open, and since this is a laptop I prefer to have swap disabled.

I then started to build bind9 for a sarge backport, which meant that a long sequence of C compiler processes were launched, each allocating some memory, working with it, terminating, next.

Being really at the limit of the available memory, the system became unresponsive - and that behavious is really bad... I thought that sooner or later it will really run out of memory, and decided to watch some TV in the meantime. One hour later when I returned, it was still torturing my HD and still unresponsive.

Apparently the compile process has been all the time just below the memory limit, causing the kernel to remove pages from memory and load them back from the disk later, which slowed everything down just horribly.

So now I'm searching for a way to prevent such situations. The traditional ulimit approach won't help - no single process was responsible for using all the memory, but each one had its reasonable share.

So dear lazyweb, is there a way to tell the kernel to reserve a share of the memory (lets say, 64 MB) for buffers and caches only? I can live with out-of-memory errors a bit early (and the just enable swap), but a massive slowdown as described above (where the kernel is apparently reading some data from the HD, then forgetting it again and replacing it with the next) must not happen that easily...

Right now I fear that you could bring down any Linux system easily with a "slow" forkbomb where each forked process allocates 100 MB and starts writing some random data to its memory, forking a new child every 50 MB or so. Neither the OOM killer, ulimit nor traditional forkbomb detectors will be able to counter that, since already a couple of processes will cause the system to become completely IO-bound. Oh, and I have no idea how Windows would react on that either. So don't assume any OS is better, just because I say Linux isn't doing perfectly well here.

If you have any tips for me, send me an email.