Description of problem: With selinux-policy-2.4.6-106 installed, I get the following messages when using yum to install an RPM with something like "yum install xv-3.10a-36.el5.x86_64.rpm" /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found/.*. Version-Release number of selected component (if applicable): selinux-policy-2.4.6-106 and yum-3.0.1-5.el5 How reproducible: Every time on all my x86_64 machines. Strangely, does not happen on my i386 machines. Steps to Reproduce: 1. Ensure selinux-policy-2.4.6-106 and yum-3.0.1-5.el5 are installed on an x86_64 machine running RHEL5.1. 2. use yum to install an RPM (e.g. yum install xv-3.10a-36.el5.x86_64.rpm) 3. Actual results: The RPM is installed, but messages like the following are also produced. /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found/.*. Expected results: I don't expect to see such messages. Additional info:
I am now using rhel5.2 I just installed the selinux-policy-2.4.6-137.1.el5_2.noarch.rpm and it's selinux-policy syblings (devel, mls, strict and targeted) and am now getting the the following errors when I install an RPM: /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found/.*. /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/\.journal. /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found.
Do you have users home directories in /usr/local? If they are real users you need to move them somewhere else. If they are services you need to make sure their shell is /sbin/nologin or /bin/false. Otherwise SELinux will think they are real users. After you change the user records run genhomedircon Then the messages should go away.
I have a RHEL 5.2 server as well with the exact same thing happening and I curretly have SELINUX disabled and I'm still getting these messages on the system which I wouldn't think would be happening and didn't happen until recently so I'm wondering if this is still a bug of some sorts. In my case the application we are running dictates that the users be setup in /usr/local. Not my preference but that is how they need to be setup or they can they we aren't doing things in a supported fashion. So is there another way to work around this rather than moving the users?
Are these real users? IE Users that actually login to the system?
Normally, these accounts are accessed via sudo. The user logs in with their normal account but when they need to do something regarding this application sudo to this user as it has the privileges they need.
Ok if you are going to disable selinux you can remove selinux-policy-targeted package from your system, which should stop these messages. You can remove the directory /etc/selinux/targeted and any files under it when the package is removed.
Worked like a charm. Much appreciated for the super fast response Dan!
>Do you have users home directories in /usr/local? If they are real >users you need to move them somewhere else. If they are services you >need to make sure their shell is /sbin/nologin or /bin/false. >Otherwise SELinux will think they are real users. Sorry, but I don't buy your explination. I just installed the latest selinux-policy RPMs on my machine. I then rebooted without ypbind running, so I don't have any users except the ones that are in /etc/passwd (none of which are homed in /usr/local). I tried installing an RPM with rpm -Uvh --test <somefile>.rpm and got the same messages about "Multiple same specifications". The problem seems to be that the file /etc/selinux/targeted/contexts/files/file_contexts.homedirs has the following lines: /usr/local/lost\+found/.* <<none>> /usr/local/\.journal <<none>> /usr/local/lost\+found -d system_u:object_r:lost_found_t:s0 which exactly match lines in the file /etc/selinux/targeted/contexts/files/file_contexts And, yes, removing the RPMs does make the problem go away, but it does not solve it.
I did not say it would solve it. The problem is you have home directories in a directory that SELinux has labeled for other purposes. So there is a conflict on labeling. SELinux will not be able to label it correctly for both purposes so it complains. Your choices are to move the home directories if they are real home directories. Put in /sbin/nologin or /bin/false so SELinux will not think they are home directories. Or if you are running selinux disabled remove the label files so other parts of the OS do not complain. Parts of the init scripts are running tools that are looking at the labels whether or not selinux is enabled. Then they complain because of the mismatch. You could also open bugzillas about the componants that are complaining about the conflict also.
Created attachment 311985 [details] /etc/passwd
>The problem is you have home directories in a directory that SELinux >has labeled for other purposes. So there is a conflict on >labeling. SELinux will not be able to label it correctly for both >purposes so it complains. Your choices are to move the home >directories if they are real home directories. Put in /sbin/nologin >or /bin/false so SELinux will not think they are home directories. Let me say this a different way. The only home directories I have on this machine are the ones that ship with rhel5.2, which does not have any references to /usr/local. I have not altered my passwd file. So, if there is some conflict with selinux and the home directories I have, it is a conflict with the stock rhel5.2 install and should be fixed. My previous post has my /etc/passwd file.
I see no home dir in /usr/local in that passwd file? I believe you are having a different problem.
>I believe you are having a different problem. agreed.
Let me put it another way. The _cause_ of my problem may be different than what bkurt was seeing. I believe the cause is that the updates to selinux-policy create multiple same specifications for /usr/local/lost\+found and /usr/local/\.journal. I have "@ Everything" installed, according to my kickstart file %packages @ Everything So, before I install the updates to selinux-policy, these are the selinux-policy RPMs I have installed: selinux-policy-2.4.6-137.el5 selinux-policy-devel-2.4.6-137.el5 selinux-policy-mls-2.4.6-137.el5 selinux-policy-strict-2.4.6-137.el5 selinux-policy-targeted-2.4.6-137.el5 Next, I install the following latest selinux-policy RPMs: selinux-policy-2.4.6-137.1.el5_2.noarch.rpm selinux-policy-devel-2.4.6-137.1.el5_2.noarch.rpm selinux-policy-mls-2.4.6-137.1.el5_2.noarch.rpm selinux-policy-strict-2.4.6-137.1.el5_2.noarch.rpm selinux-policy-targeted-2.4.6-137.1.el5_2.noarch.rpm After which, the file /etc/selinux/targeted/contexts/files/file_contexts.homedirs has entries for "/usr/local/lost\+found" and "/usr/local/\.journal" which it didn't before the update. I believe the file_contexts.homedirs is modified by the postinstall scriptlet of selinux-policy-targeted, specificly the "semodule" command. Since selinux is so difficult to disable, I am going to change the line in /etc/selinux/config to this: SELINUXTYPE="" I had already set SELINUX=disabled and "selinux=0" in /etc/grub.conf. This should prevent my machines from exploiting this bug, but there may be others that want to use selinux and may be having this problem. I still think it needs to be fixed, but I am happy to just avoid it.
One other thing. I also disable selinux in my kickstart files like so: selinux --disabled
What entry for a homedir in /usr/local was causing the problem? You say you ended up with the conflict in /usr/local and then you give me a passwd file that does not contain an entry for /usr//local?
Let me use smaller words this time. I do not have any users in /usr/local! I sent you a copy of my passwd file so that you could see that I don't have any users in /usr/local. My problem has nothing to do with users in /usr/local. my problem is caused by selinux putting entries in the file /etc/selinux/targeted/contexts/files/file_contexts.homedirs that look like this: /usr/local/lost\+found/.* <<none>> Since entries like this: /usr/local/lost\+found/.* <<none>> are already in the file /etc/selinux/targeted/contexts/files/file_contexts I get an error like this when I try to install an rpm: /etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found/.*. I am going to attach the file_contexts.homedirs file, so you can put it in your /etc/selinux/targeted/contexts/files directory and see if you get the same errors when trying to install an RPM. And, just for the last time, I have no users in /usr/local.
Created attachment 312148 [details] file_contexts.homedirs
THanks for the sarcasm. What I am trying to figure out is why the entries are there. The tool that recreates this file is genhomedircon. Obvliously it thinks you have a /usr/local user, even though the passwd file does not show one. I am doing an everything install of RHEL5 and will continue to investigate. I am also looking to make libselinux shut up with warning when it is disabled.
>THanks for the sarcasm. What I am trying to figure out is why the entries are >there. The tool that recreates this file is genhomedircon. Obvliously it >thinks you have a /usr/local user, even though the passwd file does not show >one. Ah. Hang on. My sarcasm may have been unnecessary. I have been testing a machine that does not have accounts in /usr/local, but already had the selinux updates installed. If it is the genhomedircon or semodule command that checks for users in /usr/local and adjusts file_contexts.homedirs accordingly that may explain my situation. Yes, in fact, I do have some user accounts in /usr/local, but not on my test machine but on my production machines. I hadn't thought about the file_contexts.homedirs file being created dynamicly before. I am in the middle of re-installing my test machine now, but I will get back to you when it is done. Perhaps I am having the same problem as bkurt after all. >I am doing an everything install of RHEL5 and will continue to investigate. I >am also looking to make libselinux shut up with warning when it is disabled. getting libselinux to shut up when it is disabled would be great. p.s. why doesn't selinux like having user accounts in /usr/local? Or should I not ask that question?
OK. So I used my test machine that does not have any accounts in /usr/local. I updated selinux-policy on this machine, and it didn't produce the selinux errors when I installed an RPM. Since my production machines have some user account in /usr/local via NIS, I assume that is my problem. However, I would like to see selinux not produce any errors when it is disabled. The decision of whether that should be a seperate ticket or not, I leave up to you. Either way, I now have a good workaround for this problem /etc/selinux/config SELINUXTYPE=disabled thanx, and sorry for the unnecessary sarcasm.
SELinux wants to label the homedir and the parent directory of the homedir. Homedir parent gets labeled home_root_t and actual home dirs labeled user_home_dir_t. Confined applications are not able to read home_root_t, preventing them from figuring finding out much about the users. SELinux has rules used to automatically create user_home_dir_t files in home_root_t, So if some radom app creates a directory it gets labeled correctly. The problem comes when you have the parent directory already labeled /usr/local, you end up with a conflict. genhomedircon is supposed to catch this and now write duplicate entries or even conflicting entries. I will be investigating why this happened. So current SELinux policy can not handle having user homedirectories in places like /var or /usr/local. Of course if you put them in /usr/local/home or /var/home then it would be fine.