Bug 469121 - s-c-n gives improper selinux permissions to /etc/resolv.conf
s-c-n gives improper selinux permissions to /etc/resolv.conf
Product: Fedora
Classification: Fedora
Component: system-config-network (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-29 21:08 EDT by Andre Robatino
Modified: 2008-11-04 01:04 EST (History)
2 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2008-10-29 21:08:41 EDT
Description of problem:
Using the latest test version dhcp-4.0.0-20.fc9 and related packages, after stopping and restarting eth0 with s-c-n, the selinux permissions on /etc/resolv.conf are wrong:

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

This was originally filed in bug #451560 against dhcp, but was advised there that with the latest test version of that component, this is now a new problem with s-c-n.  My OS was fully updated with the exception of using the test version of dhcp when I tested this.

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

How reproducible:

Steps to Reproduce:
1.  Boot.  At this point the permissions on /etc/resolv.conf are correct.
2.  Stop eth0 with s-c-n.
3.  Restart eth0 with s-c-n.
Actual results:
Selinux permissions on /etc/resolv.conf are now

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

Expected results:
Permissions should be same as before, namely

-rw-r--r--  root root system_u:object_r:net_conf_t:s0  /etc/resolv.conf
Comment 1 Harald Hoyer 2008-10-30 06:18:51 EDT
s-c-n does no change resolv.conf on stop/restart. This is dhcp.
Comment 2 Andre Robatino 2008-11-04 01:04:58 EST
Closing since there appears to be confirmation in bug #451560 that the cause of the bug is elsewhere (currently assigned to policycoreutils).

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