Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A while back we started authenticating users on our Linux servers against Active Directory. As far as the actual authentication part goes, things are working great.

However, one of the side effects is that Linux thinks (sort of correctly) that it has several thousands (~15-20k) of users. We've seen several issues that seem to be SELinux related (one of which is /usr/bin/install hangs, apparently due to SELinux). Some other issues include:

  • dmesg repeatedly reports that restorcon gets killed by oom-killer
  • booting on some servers take a very long time - this happens after kernel load, apparently during while reading the volume groups, but also while running the restorecon startup script.
  • yum updates hang (similar behavior to my SELinux/GNU 'install' question regarding the mmap/munmap)

We see these issues with SELinux in permissive mode. They go away when we disable SELinux completely. Disabling SELinux is an option. I'm also looking at ways to limit the number of users AD presents to Linux using an OU or group. But nerd in me always wants to know more.

So this is a pretty broad question - but anyone have any advice for dealing with SELinux with a large number of users? I'm not particularly familiar with SELinux - but this could be the learning opportunity.

share|improve this question
up vote 4 down vote accepted

This feels like a oversight regarding libselinux to me.

A 'fix' here would be to rename the old /etc/selinux/targeted/contexts/files/file_contexts.homedirs to something else. Create a new one (typically containing a few generic regular expressions which you can find at the top of the original file) and then setting that file immutable so that the policy rewriter doesn't regenerate the file (this happens when a new selinux-policy-targeted rpm is deployed).

This will prevent the CPU chew you are getting.

Your problem happens because restorecond opens this file as a reference to scan for files in users directories which must always be protected from invalid file label changes. But since your file contains thousands upon thousands of entries the scan uses up large quantities of CPU.

I suspect this was never considered when the library was created and probably needs a rethink from the SELinux end. But for now - that 'fix' should work.

share|improve this answer
will the immutability cause selinux-policy-targeted RPMs to fail fail silently at install, or kick up a fuss? P.S. Hi! – Coops Mar 21 '11 at 23:06
@Coops - No, the RPM will ignore it. SEManage does that work and semanage complains about it but the RPM seems to happily chug along no matter what the outcome of that command is. – Matthew Ife Mar 21 '11 at 23:15

It really depends on what restorecon is actually doing, but normally you don't want to run it at all, since it means that files get labeled with wrong labels and restorecon wants to make it right. The solution would be to have these files already created with the right label.

If it's actually the daemon restorecond that runs in background to do the relabeling then you can tune it so it doesn't do files where it shouldn't. See the man page of restorecond.

Do these servers deal with many files? Or do many files get created? Does it mount NFS shares?

What distro do you use? Redhat and Fedora are very responsive to selinux related problems. If the sheer size of the user database or users in groups is the real problem, they will almost certainly want to know about it. File a bug with bugzilla.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.