不久前，我们开始使用 Active Directory 对 Linux 服务器上的用户进行身份验证。就实际的身份验证部分而言，一切进展顺利。
然而，其中一个副作用是 Linux 认为（在某种程度上是正确的）它有几千 (~15-20k) 个用户。我们已经看到了几个似乎与 SELinux 相关的问题（其中之一是https://serverfault.com/questions/236419/usr-bin-install-hangs-apparently-due-to-selinux)。其他一些问题包括：
- dmesg 反复报告 restorcon 被 oom-killer 杀死
- 在某些服务器上，启动需要很长时间 - 这发生在内核加载之后，显然是在读取卷组时，但也发生在运行 restorecon 启动脚本时。
- yum 更新挂起（类似行为我的 SELinux/GNU‘安装’关于 mmap/munmap 的问题
我们在 SELinux 中发现了这些问题宽容模式。当我们完全禁用 SELinux 时，它们就会消失。禁用 SELinux 是一种选择。我还在寻找使用 OU 或组来限制 AD 向 Linux 呈现的用户数量的方法。但我内心的书呆子总是想知道更多。
所以这是一个相当广泛的问题 - 但有人对处理大量用户的 SELinux 有什么建议吗？我对 SELinux 不是特别熟悉 - 但这可能是一个学习机会。
答案1
对我来说，这感觉像是对 libselinux 的一个疏忽。
此处的“修复”方法是将旧的 /etc/selinux/targeted/contexts/files/file_contexts.homedirs 重命名为其他名称。创建一个新的（通常包含一些通用正则表达式，您可以在原始文件的顶部找到它们），然后将该文件设置为不可变，以便策略重写器不会重新生成该文件（部署新的 selinux-policy-targeted rpm 时会发生这种情况）。
这将防止 CPU 受到占用。
您的问题之所以发生，是因为 restorecond 打开此文件作为扫描用户目录中文件的参考，这些文件必须始终受到保护，以免受到无效文件标签更改的影响。但由于您的文件包含成千上万个条目，因此扫描会占用大量 CPU。
我怀疑在创建库时从未考虑过这一点，可能需要从 SELinux 方面重新考虑。但就目前而言 - 那个“修复”应该有效。
答案2
这实际上取决于 restorecon 实际在做什么，但通常你根本不想运行它，因为这意味着文件被贴上了错误的标签，而 restorecon 想要纠正它。解决方案是让这些文件已经用正确的标签创建。
如果它实际上是守护进程恢复时间在后台运行以进行重新标记，然后您可以对其进行调整，以便它不会在不该执行文件的地方执行文件。请参阅 restorecond 的手册页。
这些服务器处理很多文件吗？或者创建了很多文件？它是否挂载了 NFS 共享？
您使用什么发行版？Redhat 和 Fedora 对 selinux 相关问题反应非常灵敏。如果用户数据库或群组中用户的庞大规模才是真正的问题，他们几乎肯定会想知道。使用 bugzilla 提交错误。