> On Wednesday, July 2, 2014 7:42 AM, James Carter <jwcart2@xxxxxxxxxxxxx> wrote: > > On 07/02/2014 09:05 AM, Andy Ruch wrote: > >> Hello, >> >> I'm experiencing a pretty serious issue when making changes with > semanage. I'm running RHEL 6.5 with a custom SELinux policy. The semanage > process will lockup and use 100% of the CPU. The only way to stop it is to hard > reset the system. When I reset the system, the SELinux policy will sometimes > become corrupt, forcing me to re-install the policy. This issue will occur > roughly one third of the time I run semanage. I have seen this happen when > performing several different actions, including doing an SELinux policy RPM > update. For testing, however, I repeatedly run: >> >> semanage user -a -R sysadm_r -R staff_r -r s0-s0:c0.c1023 myuser_u >> >> >> I was able to trace it through the python code to where commit() is being > called, but I haven't dug into the C code yet. Has anyone seen anything like > this before? It could be a problem with my policy, but why doesn't it happen > every time? Any thoughts on where to look in the C code? >> >> > > How long is the semanage process at 100% before you do a hard reset? Some > operations do take a while. > > Can you reproduce the issue without your custom policy? > > -- > James Carter <jwcart2@xxxxxxxxxxxxx> > National Security Agency > When the command works, it will take a few seconds. When it fails, I've waited up to 10 minutes and it still never returns. Unfortunately, my system is pretty customized so I can't run the targeted policy on there. When I do a straight RHEL install, I can't get it to fail (in the limited testing that I did). That's why I suspect it's my policy, but I'm not sure why it would only fail some of the time. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
