Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451560 - bootup/shutdown error creating or deleting /etc/resolv.conf.predhclient.eth0
Summary: bootup/shutdown error creating or deleting /etc/resolv.conf.predhclient.eth0
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: policycoreutils
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-15 20:39 UTC by Andre Robatino
Modified: 2008-11-04 14:09 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-04 14:09:44 UTC


Attachments (Terms of Use)
Patch to maintain proper SELinux context (deleted)
2008-06-30 19:41 UTC, Daniel Walsh
no flags Details | Diff

Description Andre Robatino 2008-06-15 20:39:52 UTC
Description of problem:
Occasionally, there is a bootup or shutdown error which appears concerning not
being able to create or delete /etc/resolv.conf.predhclient.eth0 (for the exact
messages, google this filename).  The following are audit messages in
/var/log/messages appearing at the same time.  The ethernet interface came up
normally despite the error message.  I was able to fix this once before by
deleting this file manually but that shouldn't be necessary.

Jun 15 15:31:37 localhost kernel: e100: eth0: e100_watchdog: link up, 100Mbps,
full-duplex
Jun 15 15:31:37 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 15 15:31:37 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 15 15:31:37 localhost kernel: type=1400 audit(1213558295.809:4): avc: 
denied  { write } for  pid=1790 comm="cp" name="resolv.conf.predhclient.eth0"
dev=dm-0 ino=3687891 scontext=system_u:system_r:dhcpc_t:s0
tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
Jun 15 15:31:37 localhost kernel: type=1400 audit(1213558295.809:5): avc: 
denied  { unlink } for  pid=1790 comm="cp" name="resolv.conf.predhclient.eth0"
dev=dm-0 ino=3687891 scontext=system_u:system_r:dhcpc_t:s0
tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
Jun 15 15:31:38 localhost rpc.statd[1914]: Version 1.1.2 Starting

Version-Release number of selected component (if applicable):
audit-1.7.4-1.fc9.i386

How reproducible:
don't know

Steps to Reproduce:
don't know how

Comment 1 Steve Grubb 2008-06-23 21:00:07 UTC
You may have some mislabled files. You can try fixing them by:

restorecon -R /etc

The above message doesn't look like an audit problem. Its just the bearer of bad
news much like syslog is.

Comment 2 Andre Robatino 2008-06-24 00:21:34 UTC
I deleted the offending file manually a while ago to get rid of the error
message, and it hasn't reappeared yet.  The question is, if what you are saying
is true, is how did the files get mislabeled in the first place?  I never run
any SELinux-related commands manually.  If you can make an educated guess I'll
reassign this bug to another component.

By the way, when the error message was appearing, it didn't seem to be
interfering with the normal operation of the network on bootup or shutdown, it
was simply annoying.

Comment 3 Andre Robatino 2008-06-24 01:45:53 UTC
One other possibly important detail is that I'm using network, not NetworkManager.

Comment 4 Steve Grubb 2008-06-24 02:18:51 UTC
Do you have restorecond installed and running? Its job is to fix the contexts of
files that are not created in a SE Linux safe way. I don't have much else to
offer since I work on audit and not SE Linux policy/utilities. Your bug is not
with audit, but likely a SE Linux component or policy. Audit is a logging system
much like syslog and not the origin of the problem regardless of what the
message says. :)

Comment 5 Andre Robatino 2008-06-24 02:23:42 UTC
I do have a restorecond process running (I basically just left everything
SELinux-related at its defaults since I don't understand it).  I'll switch the
component to selinux-policy.

Comment 6 Daniel Walsh 2008-06-30 17:11:11 UTC
Some process created the file with the wrong context.  Potentially
system-config-network.  If a file is created in the /etc by a user or a process
that is run by a user without a transition, the file would be created as etc_t.
 This tool has a bug and should have created the file with the same context as
/etc/resolv.conf which is net_conf_t.  If you know of a tool that might have
created the file, then we need to fix that tool.

Comment 7 Andre Robatino 2008-06-30 18:30:27 UTC
[andre@localhost etc]$ ls -lZ resolv.conf*
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf.predhclient.eth0

Then I used system-config-network to deactivate the ethernet interface.

[andre@localhost etc]$ ls -lZ resolv.conf*
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf

Finally, I used system-config-network to activate the ethernet interface again.

[andre@localhost etc]$ ls -lZ resolv.conf*
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf
-rw-r--r--  root root unconfined_u:object_r:etc_t:s0   resolv.conf.predhclient.eth0

Looks like your suspicion is correct.  Presumably I will get the same error upon
shutdown again.


Comment 8 Daniel Walsh 2008-06-30 19:41:50 UTC
Created attachment 310613 [details]
Patch to maintain proper SELinux context

When dhcp-client is creating files it is creating them with the wrong context.

Comment 9 Daniel Walsh 2008-06-30 19:42:38 UTC
I mean /sbin/dhclient-script


Comment 10 Andre Robatino 2008-07-02 16:29:37 UTC
When rebooting, I did indeed get the same error.  I then deleted the file manually.

Comment 11 Fedora Update System 2008-08-06 19:58:04 UTC
dhcp-4.0.0-18.fc9 has been submitted as an update for Fedora 9

Comment 12 Fedora Update System 2008-08-12 18:27:10 UTC
dhcp-4.0.0-18.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7234

Comment 13 Fedora Update System 2008-09-16 23:25:44 UTC
dhcp-4.0.0-18.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Andre Robatino 2008-09-27 22:15:06 UTC
I received update emails for both dhcp-4.0.0-17.fc9 and dhcp-4.0.0-18.fc9, however only the first has been pushed.  The current version in the updates-newkey repo is still 17.

Comment 15 Andre Robatino 2008-09-28 21:54:27 UTC
Should also mention that release 18 doesn't even exist in the testing repo anymore, so there's no easy way to get it.  Someone please get 18 released, to match the update email that went out almost 2 weeks ago and finally fix this bug.

Comment 16 David Cantrell 2008-09-30 23:40:45 UTC
-18 has been pushed to the stable updates repository.

Comment 17 Andre Robatino 2008-10-01 07:08:45 UTC
I applied the libdhcp4client-4.0.0-18.fc9.i386 and dhclient-4.0.0-18.fc9.i386 updates and then tried bringing eth0 down and up again using system-config-network.  Below is what happens to resolv.conf* :

before bringing eth0 down:

[andre@localhost etc]$ ls -lZ resolv.conf*
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf.bak
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf.predhclient.eth0

after bringing eth0 down:

[andre@localhost etc]$ ls -lZ resolv.conf*
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf.bak

after bringing eth0 back up:

[andre@localhost etc]$ ls -lZ resolv.conf*
-rw-r--r--  root root unconfined_u:object_r:net_conf_t:s0 resolv.conf
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf.bak
-rw-r--r--  root root system_u:object_r:net_conf_t:s0  resolv.conf.predhclient.eth0

The problem with resolv.conf.predhclient.eth0 is fixed, but the permissions on resolv.conf have changed.  Is this a problem?

Comment 18 Fedora Update System 2008-10-01 21:09:55 UTC
dhcp-4.0.0-20.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/dhcp-4.0.0-20.fc9

Comment 19 David Cantrell 2008-10-01 21:20:25 UTC
Ahh, good catch.  I've think I have it fixed in dhcp-4.0.0-20.fc9.  I'm submitted that and pushed it to updates-testing.  Please try it when it shows up.

Thanks.

Comment 20 Fedora Update System 2008-10-03 22:33:16 UTC
dhcp-4.0.0-20.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8594

Comment 21 Andre Robatino 2008-10-04 05:22:59 UTC
Broken worse than before.  The permissions on resolv.conf.predhclient.eth0 are wrong immediately after booting, but are corrected if one stops and restarts eth0 with s-c-network.  On the other hand, the permissions on resolv.conf start out correct, but are wrong after stopping/restarting eth0.  To make sure this works properly, please make sure that the permissions on ALL /etc/resolv.conf* files are correct both immediately after booting, AND again after stopping/restarting eth0.

I tried leaving negative feedback at the given URL, but there is a server error preventing it.

Comment 22 Andre Robatino 2008-10-12 14:55:14 UTC
Ignore what I said about the permissions on resolv.conf.predhclient.eth0 being wrong after booting - I just checked, and all resolv.conf* files had the correct permissions before stopping and restarting eth0 with s-c-n (but not after).  There must have been bad permissions left over from before.  The only remaining problem I see is that after stopping and restarting eth0 with s-c-network, the permissions on /etc/resolv.conf are wrong:

-rw-r--r--  root root unconfined_u:object_r:net_conf_t:s0 /etc/resolv.conf

So it's broken about as bad as before, just in a different way.  I was able to leave feedback earlier, but forgot to log in, so it's as "Anonymous Tester".

Comment 23 David Cantrell 2008-10-29 23:48:51 UTC
Sounds like a new problem now, but with s-c-network.

File a new bug against that component rather than changing the ownership of this component.

Thanks.

Comment 24 Andre Robatino 2008-10-30 01:09:36 UTC
Filed new bug #469121.

Comment 25 Andre Robatino 2008-10-30 10:24:46 UTC
Have been told over there that this is, in fact, still a dhcp bug, since s-c-n does not change resolv.conf on stop/restart.  Reopening.

Comment 26 David Cantrell 2008-11-04 03:33:31 UTC
My knowledge going in to this:

/sbin/dhclient-script calls restorecon to make sure selinux context is set correctly on /etc/resolv.conf.predhclient.* files as well as the /etc/ntp.conf backup files.  dhclient-script calls change_resolv_conf() from /etc/sysconfig/network-scripts/network-functions to actually write out a new /etc/resolv.conf file.  change_resolv_conf() calls restorecon to set the selinux linux context on the new /etc/resolv.conf.

Investigating has revealed the following:

1) restorecond monitors /etc/resolv.conf and resets the selinux context.  Both system_u:object_r:etc_t:s0 and unconfined_u:object_r:etc_t:s0 appear to please restorecond.

2) If I down the interface in s-c-network, remove all existing /etc/resolv.conf* files, and create a new /etc/resolv.conf file using vim, the context is system_u:object_r:etc_t:s0.

3) Bringing the interface up in s-c-network, the new /etc/resolv.conf file is now unconfined_u:object_r:etc_t:s0 and the /etc/resolv.conf.predhclient.* file is system_u:object_r:etc_t:s0.

4) Running restorecon /etc/resolv.conf does not change unconfined_u to system_u, so I don't know what's causing that.  Running it with -vv shows that it tries to reset it to system_u:object_r:etc_t:s0, but doesn't:

    # restorecon -vv /etc/resolv.conf
    restorecon reset /etc/resolv.conf context unconfined_u:object_r:net_conf_t:s0->system_u:object_r:net_conf_t:s0
    # ls -lZ /etc/resolv.conf
    -rw-r--r--  root root unconfined_u:object_r:net_conf_t:s0 /etc/resolv.conf

restorecon seems to be failing here, or it's failing because a policy change needs to take place.  I'm not quite sure.  Reassigning to policycoreutils.

Comment 27 Daniel Walsh 2008-11-04 14:09:44 UTC
unconfined_u:object_r:net_conf_t:s0 is the right context for /etc/resolv.conf if a user (unconfined_u) through the use of s-c-n has manipulated the file.  system_u means that a system service manipulated the file.  SELinux confined applications will not care about it, they are only concerned about the net_conf_t (The type).  So the system seems to be working correctly.

If you want to change the context to system_u, you can force it with a restorecon -F /etc/resolv.conf.  But the user component of the SELinux policy is not important when making these security decisions with SELinux targeted policy.


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