Bug 469964 - selinux-policy complains "Multiple different specifications for /etc"
Summary: selinux-policy complains "Multiple different specifications for /etc"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 8
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-04 22:15 UTC by Michal Jaegermann
Modified: 2008-11-05 22:54 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-11-05 20:31:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2008-11-04 22:15:50 UTC
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 14:52:56 UTC
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 20:02:47 UTC
> 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 20:31:47 UTC
Run 
#genhomedircon
#restorecon -R -v /etc

Should clean it up.

Comment 4 Michal Jaegermann 2008-11-05 21:13:52 UTC
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 21:45:58 UTC
Try

# setenforce 0
# genhomedircon
# restorecon -R -v /etc

Comment 6 Michal Jaegermann 2008-11-05 22:19:46 UTC
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 22:54:23 UTC
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.