Bug 469121

Summary:	s-c-n gives improper selinux permissions to /etc/resolv.conf
Product:	[Fedora] Fedora	Reporter:	Andre Robatino <robatino>
Component:	system-config-network	Assignee:	Harald Hoyer <harald>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	harald, jmoskovc
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-11-04 06:04:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andre Robatino 2008-10-30 01:08:41 UTC

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):
system-config-network-1.5.10-1.fc9.noarch

How reproducible:
always

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 10:18:51 UTC

s-c-n does no change resolv.conf on stop/restart. This is dhcp.

Comment 2 Andre Robatino 2008-11-04 06:04:58 UTC

Closing since there appears to be confirmation in bug #451560 that the cause of the bug is elsewhere (currently assigned to policycoreutils).