Bug 421101 - selinux-policy-targeted consumes 100% CPU for very long time.
selinux-policy-targeted consumes 100% CPU for very long time.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-12 04:24 EST by Helge Deller
Modified: 2008-08-26 06:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-17 16:55:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Try this genhomedircon (11.64 KB, application/octet-stream)
2007-12-12 10:06 EST, Daniel Walsh
no flags Details

  None (edit)
Description Helge Deller 2007-12-12 04:24:16 EST
Description of problem:
When installing selinux-policy-targeted (via yum) 'genhomedircon' will start 
and consume 100% CPU. I just killed genhomedircon after one hour.

Version-Release number of selected component (if applicable):
- affected version: selinux-policy-targeted  2.6.4-61.fc7 (and the version 
which was shipped before this one).

How reproducible:
always

Steps to Reproduce:
1. yum install selinux-policy-targeted 
  
Actual results:
uses 100% CPU time.

Expected results:
should finish in a few seconds

Additional info:

I'm not sure what the problem is.
We are running a kind of "Terminal Server" here. This means there are usually 
30-50 people logged in remotely.
Some home directories are NFS-mounted shares, some are 
local /home/LTS/<username> style directories.
I assume the main reason for the slow execution of genhomedircon might be 
related to NIS-users and NFS shares. Overall, the NIS service holds more than 
40.000 NIS users. Maybe genhomedircon has some non-efficient algoritrhm to 
hold the usernames and always ask the NIS server over and over again.

top reported:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM     TIME+  COMMAND
 7211 root      20   0 15072  12m 2104 R  100  0.3   10:56.64 genhomedircon

I attached strace to this process, and the following came over and over again:
close(4)                                = 0
munmap(0xb7f5d000, 4096)                = 0
open("/etc/selinux/targeted/contexts/files/file_contexts", O_RDONLY|
O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=132169, ...}) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=132169, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7f5d000
read(4, "/.*\tsystem_u:object_r:default_t:"..., 8192) = 8192
read(4, ")?\tsystem_u:object_r:lvm_etc_t:s"..., 4096) = 4096
read(4, "cups/cgi-bin/.*\t--\tsystem_u:obje"..., 4096) = 4096
read(4, "hapengine\\.so.*\t--\tsystem_u:obje"..., 4096) = 4096
read(4, "adspa/highpass_iir_1890\\.so\t--\ts"..., 4096) = 4096
read(4, "_u:object_r:innd_etc_t:s0\n/var/l"..., 4096) = 4096
read(4, "opt/Adobe(/.*?)/nppdf\\.so\t--\tsys"..., 4096) = 4096
read(4, "ect_r:removable_device_t:s0\n/var"..., 4096) = 4096
read(4, "_u:object_r:xend_var_lib_t:s0\n/v"..., 4096) = 4096
read(4, "0\n/sbin/ipchains.*\t--\tsystem_u:o"..., 4096) = 4096
read(4, "\tsystem_u:object_r:iptables_exec"..., 4096) = 4096
read(4, "d.log\t--\tsystem_u:object_r:ricci"..., 4096) = 4096
read(4, "\tsystem_u:object_r:amavis_exec_t"..., 4096) = 4096
read(4, "system_u:object_r:bin_t:s0\n/etc/"..., 4096) = 4096
read(4, "u:object_r:lib_t:s0\n/var/qmail/s"..., 4096) = 4096
read(4, "o.*\t--\tsystem_u:object_r:shlib_t"..., 4096) = 4096
read(4, "0\n/var/lib/squirrelmail/prefs(/."..., 4096) = 4096
read(4, "ject_r:rpm_exec_t:s0\n/etc/ppp\t-d"..., 4096) = 4096
read(4, "_u:object_r:httpd_config_t:s0\n/d"..., 4096) = 4096
read(4, "ystem_u:object_r:ntpd_key_t:s0\n/"..., 4096) = 4096
read(4, "stem_u:object_r:lvm_exec_t:s0\n/s"..., 4096) = 4096
read(4, "--\tsystem_u:object_r:pppd_exec_t"..., 4096) = 4096
read(4, ":rwho_exec_t:s0\n/usr/bin/screen\t"..., 4096) = 4096
read(4, "tpdate\t--\tsystem_u:object_r:ntpd"..., 4096) = 4096
read(4, "\t--\tsystem_u:object_r:mozilla_co"..., 4096) = 4096
read(4, "-\tsystem_u:object_r:games_exec_t"..., 4096) = 4096
read(4, "t_r:nfsd_exec_t:s0\n/usr/sbin/in\\"..., 4096) = 4096
read(4, "bject_r:ptal_exec_t:s0\n/etc/name"..., 4096) = 4096
read(4, "p-server\t--\tsystem_u:object_r:ro"..., 4096) = 4096
read(4, ":qmail_queue_exec_t:s0\n/var/qmai"..., 4096) = 4096
read(4, "b/mailman/bin/mailmanctl\t--\tsyst"..., 4096) = 4096
read(4, "ig-httpd\t--\tsystem_u:object_r:bi"..., 4096) = 1097
read(4, "", 4096)                       = 0
futex(0x84f4f48, FUTEX_WAKE, 1)         = 0
futex(0x84f4f48, FUTEX_WAKE, 1)         = 0
futex(0x84f4f48, FUTEX_WAKE, 1)         = 0
futex(0x84f4f48, FUTEX_WAKE, 1)         = 0
futex(0x84f4f48, FUTEX_WAKE, 1)         = 0
futex(0x84f4f48, FUTEX_WAKE, 1)         = 0
<many more of this futexes, then start at top again).
Comment 1 Daniel Walsh 2007-12-12 10:06:08 EST
Created attachment 285781 [details]
Try this genhomedircon

There is a bug in the genhomedircon that is compiling the regexs many times. 
if this genhomedircon fixes your problem, I will back port.
Comment 2 Helge Deller 2007-12-13 11:47:24 EST
Hi Daniel,
ok, I tested you genhomedircon file. Still runs slooow.

Problem does not look like regex or NIS users, but instead the amount of NFS 
directories which are mounted via autofs on the system. It's a large autofs 
setup.
When I install with your genhomedircon, I get the following list on the 
screen:
/usr/sap/PR6
/usr/sap/AFP
/usr/sap/K7C
/usr/sap/C7E
/usr/sap/D53
/usr/sap/Q9B
/usr/sap/A15
/usr/sap/KMF
<and many more, each printed line taking around 2 seconds>
I assume since genhomedircon wants to touch those directories, automounter 
jumps in and tries to mount those directories.

Does it makes sense to try genhomedircon on NFS directories? In our case those 
NFS directories are NFSv3 (and even NFSv2) where the additional selinux 
attributes don't work anyway.
Comment 3 Daniel Walsh 2007-12-13 15:10:45 EST
No genhomedircon does nothing on nfs homedirs.  

The script should not be touching the homedir.  In Fedora 8 this script is
changed to C Code. 

So the best thing for you to do is disable the use of the passwd file

If you edit genhomedircon and modify the line

        usepwd = 1

to 

        usepwd = 0

It should work much better for you. 
Comment 4 Helge Deller 2007-12-14 07:25:49 EST
Hi Daniel,
no, "usepwd" would not change anything.

The directories I mentioned above, e.g. /usr/sap/PR6, are not home directories. 
These are standard NFS-directories.

I think genhomedircon should check if the current directory is a NFS-directory, 
and if it is, it should not try to do anything on it.
Comment 5 Daniel Walsh 2007-12-17 10:41:07 EST
usepwd tells genhomedircon to not look use getpw calls to list all users on the
system.  It uses this information to find all homedirectories, and then
potentially list set up the labeling for these directories.

Are sap enties added to the passwd file?  If yes what is their shell entry?  Are
these accounts that you login to?  If not thier shells should be /sbin/nologin
/usr/sap/PR6
/usr/sap/AFP
/usr/sap/K7C
/usr/sap/C7E
/usr/sap/D53
/usr/sap/Q9B
/usr/sap/A15
/usr/sap/KMF
Comment 6 Helge Deller 2007-12-17 11:50:55 EST
Ok, tried it, and it works great!!!
I tried your genhomedircon file from comment #1 and applied this diff to it:

--- genhomedircon       2007-12-17 17:37:09.000000000 +0100
+++ /usr/sbin/genhomedircon     2007-12-17 17:42:11.000000000 +0100
@@ -123,7 +123,7 @@
        sys.exit(1)

 class selinuxConfig:
-       def __init__(self, selinuxdir = "/etc/selinux", type = "targeted", 
usepwd = 1):
+       def __init__(self, selinuxdir = "/etc/selinux", type = "targeted", 
usepwd = 0):
                self.semanageHandle = semanage_handle_create()
                self.semanaged = semanage_is_managed(self.semanageHandle)
                if self.semanaged:
@@ -384,7 +384,7 @@
 # based off the homedir_template file, entries in the password file, and
 #
 try:
-       usepwd = 1
+       usepwd = 0
        directory = "/etc/selinux"

I think the reason why it worked is, is that - as you explained - usepwd 
ignores the passwd file. In our case, we don't have any users in passwd file, 
but instead the passwd file refers to NIS, and many users are NIS users.
As such I found e.g. the following users in our NIS database:
pr6adm:NOLOGIN:5956:79:SAP-User for PR6:/usr/sap/PR6/home:/bin/csh
sapafp:NOLOGIN:6999:79:SAP-User for AFP:/usr/sap/AFP/home:/bin/csh
<and so on>

Will you provide an updated policycoreutils package which has "usepwd=0" in 
it's /usr/sbin/genhomedircon script?
Comment 7 Daniel Walsh 2007-12-17 16:55:11 EST
No since this is only a workaround.

You should fix these entries in your NIS database to have a shell of 

/sbin/nologin or /bin/false

I believe this would have the same effect of the usepwd=0.

The purpose of genhomedircon is to read the password entries to find if a new
"login user" has been added with a non-default directory.  The way genhomedircon
figures out if the user is a login user, is by looking at UID>500 and a shell in
/etc/shells that is not /bin/false or /sbin/nologin.
Comment 8 Helge Deller 2008-08-26 06:04:35 EDT
internal SAP IT/IBC message: 2668489/2007

Note You need to log in before you can comment on or make changes to this bug.