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).
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.
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.
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.
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.
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
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?
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.
internal SAP IT/IBC message: 2668489/2007