This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 435961 - selinux-policy-2.4.6-106 produces messages with yum
selinux-policy-2.4.6-106 produces messages with yum
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
5.1
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-04 12:22 EST by K. Scott Rowe
Modified: 2008-07-18 13:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-16 12:05:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/etc/passwd (2.81 KB, application/octet-stream)
2008-07-16 15:16 EDT, K. Scott Rowe
no flags Details
file_contexts.homedirs (18.49 KB, application/octet-stream)
2008-07-18 11:21 EDT, K. Scott Rowe
no flags Details

  None (edit)
Description K. Scott Rowe 2008-03-04 12:22:02 EST
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:
Comment 1 K. Scott Rowe 2008-07-10 17:35:25 EDT
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.
Comment 3 Daniel Walsh 2008-07-16 12:05:40 EDT
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.
Comment 4 Kurt Bechstein 2008-07-16 12:22:47 EDT
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?
Comment 5 Daniel Walsh 2008-07-16 12:31:44 EDT
Are these real users?  IE Users that actually login to the system?
Comment 6 Kurt Bechstein 2008-07-16 12:47:17 EDT
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.
Comment 7 Daniel Walsh 2008-07-16 12:59:59 EDT
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.
Comment 8 Kurt Bechstein 2008-07-16 13:33:18 EDT
Worked like a charm.  Much appreciated for the super fast response Dan!
Comment 9 K. Scott Rowe 2008-07-16 13:37:54 EDT
>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.
Comment 10 Daniel Walsh 2008-07-16 14:53:52 EDT
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.
Comment 11 K. Scott Rowe 2008-07-16 15:16:47 EDT
Created attachment 311985 [details]
/etc/passwd
Comment 12 K. Scott Rowe 2008-07-16 15:17:24 EDT
>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.
Comment 13 Daniel Walsh 2008-07-16 15:30:27 EDT
I see no home dir in /usr/local in that passwd file?

I believe you are having a different problem.
Comment 14 K. Scott Rowe 2008-07-16 17:05:38 EDT
>I believe you are having a different problem.

agreed.
Comment 15 K. Scott Rowe 2008-07-18 10:45:33 EDT
Let me put it another way.  The _cause_ of my problem may be different than
what bkurt@bgsu.edu 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.
Comment 16 K. Scott Rowe 2008-07-18 10:56:57 EDT
One other thing.  I also disable selinux in my kickstart files like so:

  selinux --disabled
Comment 17 Daniel Walsh 2008-07-18 11:08:25 EDT
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?

Comment 18 K. Scott Rowe 2008-07-18 11:20:59 EDT
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.


Comment 19 K. Scott Rowe 2008-07-18 11:21:49 EDT
Created attachment 312148 [details]
file_contexts.homedirs
Comment 20 Daniel Walsh 2008-07-18 11:39:25 EDT
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.
Comment 21 K. Scott Rowe 2008-07-18 11:53:03 EDT
>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@bgsu.edu 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?
Comment 22 K. Scott Rowe 2008-07-18 12:48:40 EDT
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.
Comment 23 Daniel Walsh 2008-07-18 13:13:08 EDT
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.

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