Bug 426967 - selinux dislikes home-dirs in /usr/local: Multiple same specifications
Summary: selinux dislikes home-dirs in /usr/local: Multiple same specifications
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
(Show other bugs)
Version: 8
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-29 01:12 UTC by Andreas M. Kirchwitz
Modified: 2008-01-08 18:19 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-08 18:19:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/selinux/targeted/contexts/files/file_contexts.homedirs (5.15 KB, text/plain)
2007-12-29 01:13 UTC, Andreas M. Kirchwitz
no flags Details
/etc/selinux/targeted/modules/active/file_contexts.homedirs (5.15 KB, text/plain)
2007-12-29 01:13 UTC, Andreas M. Kirchwitz
no flags Details

Description Andreas M. Kirchwitz 2007-12-29 01:12:13 UTC
Description of problem:
If users have their home-directory located somewhere in /usr/local, then,
during the update process of package "selinux-policy-targeted", a new section
(besides the existing ones for /home and /root) is added for /usr/local to
the selinux policy files

The new section is basically the same as for home-directories in /home
and /root, but now with all entries starting with /usr/local. Unfortunately,
some of these entries conflict with the (already existing) global entries in

Version-Release number of selected component (if applicable):

The error exists for about the last 3-4 updates of "selinux-policy-targeted".
The problem isn't new. It occured in most Fedora versions, but usually went
away after next update of "selinux-policy-targeted". However, this time it
didn't go away after a couple of updates.

How reproducible:
update from previous to current version of "selinux-policy-targeted",
for example, with "yum update"

Steps to Reproduce:
1. "yum update" or "rpm -Uvh selinux-policy-targeted-3.0.8-69.fc8.noarch.rpm"
Actual results:
# yum update
---> Package selinux-policy.noarch 0:3.0.8-72.fc8 set to be updated
---> Package selinux-policy-targeted.noarch 0:3.0.8-72.fc8 set to be updated
---> Package selinux-policy-devel.noarch 0:3.0.8-72.fc8 set to be updated
  Updating  : selinux-policy               ####################### [ 2/24] 
  Updating  : selinux-policy-targeted      ####################### [ 3/24] 
/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.
  Updating  : selinux-policy-devel         ####################### [ 4/24] 

The error messages also occur for other selinux related tools that
deal with the policy files. Don't know if this has any security
implications, but to me, it just looks like a harmless (but annoying)
error message.

The following files contain new entries for /usr/local
which conflict with global settings (file_contexts, see above):

Removing all lines beginning with /usr/local (or at least
the ones with "lost+found" and ".journal") helps.

Expected results:
no error messages (Multiple same specifications) during update,
and valid policy files (file_contexts.homedirs) afterwards

Additional info:
see attached policy files
(the section with /usr/local entries is new and conflicts with global policy)

Comment 1 Andreas M. Kirchwitz 2007-12-29 01:13:20 UTC
Created attachment 290512 [details]

Comment 2 Andreas M. Kirchwitz 2007-12-29 01:13:38 UTC
Created attachment 290513 [details]

Comment 3 Daniel Walsh 2007-12-31 11:52:00 UTC
SELinux can not handle user homedirectories in /usr/local.  SELinux wants to
label the parent directory of the user homedir as home_root_t and then the
homedir as user_home_dir_t.  If you put the home directories in a location with
a default label that SELinux wants to be different the home_root_t, you will
generate this conflict.  

If these accounts are actually user homedirectories then SELinux would work if
you move them to a subdirectory /usr/local/home for example.  If these
directories are not really user home directories but a service directories, then
you need to fix the password entry to not use a real shell. /sbin/nologin or

Comment 4 Andreas M. Kirchwitz 2008-01-08 14:43:35 UTC
Okay, now I understand. Thanks for the explanation. Helps a lot!

My accounts in /usr/local are all service accounts for additional
software I installed into /usr/local. Most of them have /sbin/nologin,
but a few require a real shell. How does SELinux checks for the shell?
Is there a positive list containing all known shells (sh, bash etc.)
or a negative list containing non-shells (/sbin/nologin)? Or does it
scan /etc/selinux/targeted/contexts/files/file_contexts for entries
of type "shell_exec_t"?

Comment 5 Daniel Walsh 2008-01-08 18:19:35 UTC

Contains all valid shells.  /sbin/nologin and /bin/false are hard coded
negatives and UID < 500 are ignored.

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