Bug 469964 - selinux-policy complains "Multiple different specifications for /etc"
selinux-policy complains "Multiple different specifications for /etc"
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-04 17:15 EST by Michal Jaegermann
Modified: 2008-11-05 17:54 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-05 15:31:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2008-11-04 17:15:50 EST
Description of problem:

Various selinux operations, like running
 
   restorecon -r /home/<some_user>

produce the following message on a terminal: "/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /etc  (system_u:object_r:home_root_t:s0 and system_u:object_r:etc_t:s0)".

On the system in question 'ls -Zd /etc' actually prints 'drwxr-xr-x  root root system_u:object_r:etc_t          /etc'


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.0.8-121.fc8

Expected results:
No spurious messages.
Comment 1 Daniel Walsh 2008-11-05 09:52:56 EST
You have a user account with a homedir in /etc?

Is this a service?

If it is a service it should have an shell of /bin/false or /sbin/nologin
Comment 2 Michal Jaegermann 2008-11-05 15:02:47 EST
> You have a user account with a homedir in /etc?

As a matter of fact there are three such "active" accounts:

xfs:x:43:43:X Font Server:/etc/X11/fs:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
sipxchange:x:551:551:sipX service daemon:/etc/sipxpbx:/sbin/nologin

Something added that "sipxchange" relatively recently.

> If it is a service it should have an shell of /bin/false or /sbin/nologin

I used 'chsh' to replace that shell with /sbin/nologin (nothing from
that "sip..." is running yet).  That, unfortunately, does not seem to
help very much.

After "# restorecon -Rv /etc" I see:

/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /etc  (system_u:object_r:home_root_t:s0 and system_u:object_r:etc_t:s0).
restorecon reset /etc/sipxpbx context unconfined_u:object_r:unconfined_home_t:s0->unconfined_u:object_r:unconfined_home_dir_t:s0
restorecon reset /etc/resolv.conf context unconfined_u:object_r:unconfined_home_t:s0->system_u:object_r:net_conf_t:s0
restorecon reset /etc/hosts context unconfined_u:object_r:unconfined_home_t:s0->system_u:object_r:etc_t:s0
restorecon reset /etc/sysconfig/networking/profiles/default/resolv.conf context system_u:object_r:net_conf_t:s0->unconfined_u:object_r:unconfined_home_t:s0
restorecon reset /etc/sysconfig/networking/profiles/default/hosts context system_u:object_r:etc_t:s0->unconfined_u:object_r:unconfined_home_t:s0

Moreover '# ls -Zd a2ps acpi alternatives avahi' prints now:

drwxr-xr-x  root root unconfined_u:object_r:unconfined_home_dir_t:s0 a2ps
drwxr-xr-x  root root unconfined_u:object_r:unconfined_home_dir_t:s0 acpi
drwxr-xr-x  root root unconfined_u:object_r:unconfined_home_dir_t:s0 alternatives
drwxr-xr-x  root root unconfined_u:object_r:unconfined_home_dir_t:s0 avahi

and similar.  As a matter of fact nearly all subdirectories in /etc end up with type either unconfined_home_dir_t or home_root_t and even after an explicit
'chcon -t etc_t /etc' running 'restorecon -R /etc' reverts that to home_root_t.  Now what?

BTW - after that "sip..." things were added selinux-policy and selinux-policy-targeted packages were updated twice.
Comment 3 Daniel Walsh 2008-11-05 15:31:47 EST
Run 
#genhomedircon
#restorecon -R -v /etc

Should clean it up.
Comment 4 Michal Jaegermann 2008-11-05 16:13:52 EST
It would be nice.

# genhomedircon 
/usr/sbin/semodule:  Could not begin transaction:  Permission denied

A strace fragment looks like this:
.......
read(255, "#!/bin/sh\n/usr/sbin/semodule -Bn"..., 33) = 33
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f6d708) = 3440
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x807b570, [], 0}, {SIG_DFL}, 8) = 0
waitpid(-1, /usr/sbin/semodule:  Could not begin transaction:  Permission denied
[{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0) = 3440
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
.......

After all these attempts to fix things I am only bombarded with avc in /var/log/messages and all of this was not there before.  Sigh!

Luckily a remote login still works as this is a remote machine for me.
Comment 5 Daniel Walsh 2008-11-05 16:45:58 EST
Try

# setenforce 0
# genhomedircon
# restorecon -R -v /etc
Comment 6 Michal Jaegermann 2008-11-05 17:19:46 EST
Command from comment #5 apparently helped.  Thanks!  At least labels in /etc look sane.  Also the message which started all of this disappeared.

I doubt that I would be able to extricate myself without handholding. In particular I would not guess that 'genhomedircon' can/should be used; especially because the only documentation for that seem to be available only as /usr/share/man/ru/man8/genhomedircon.8.gz.  As it happens I am able to read that, once I know it is there, although I am not sure if I am much wiser after this lecture. Looking at 'man semodule' also does not help me very much.  Sigh!
Comment 7 Daniel Walsh 2008-11-05 17:54:23 EST
Actually a bug in genhomedircon caused your problem in the first place.  It is supposed to stop you from getting into the problem.

genhomedircon is usually run within the semodule or semanage commands.  It is also run when selinux-policy is updated.  

It used to be a separate command but now it is part of the management infrastructure.  It's job is to try to figure out where users home directories are, and then setup the labeling correctly.  If you have a service with a uid > 500 and a login shell it thinks it is a user account and attempts to setup the labeling for the homedir.  In this case it labeled /etc as /home_root_t and everything went nuts.

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