Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 814116

Summary: /etc/dhcp/dhclient.d/nis.sh: /etc/yp.conf: Permission denied
Product: Red Hat Enterprise Linux 6 Reporter: Dennis Schridde <heri>
Component: ypbindAssignee: Honza Horak <hhorak>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-27 15:21:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dennis Schridde 2012-04-19 09:31:59 UTC
Description of problem:
/etc/network-scripts/ifcfg-eth0:
NM_CONTROLLED="no"
BOOTPROTO="dhcp"

# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...mv: cannot move `/etc/yp.conf' to `/var/lib/dhclient/yp.conf.predhclient.eth0': Permission denied
/etc/dhcp/dhclient.d/nis.sh: line 55: /etc/yp.conf: Permission denied
/etc/dhcp/dhclient.d/nis.sh: line 63: /etc/yp.conf: Permission denied
 done.
                                                           [  OK  ]

Version-Release number of selected component (if applicable):
ypbind-1.20.4-29.el6.x86_64

Comment 2 Dennis Schridde 2012-04-19 09:37:08 UTC
See also: 593278 (I cannot update the bug form field - please add it there if you have the permission)

Comment 3 Dennis Schridde 2012-04-19 09:47:46 UTC
This seems to be a workaround:
# fixfiles onboot

Comment 4 Honza Horak 2012-04-19 11:24:58 UTC
Can you tell me what SELinux context /etc/yp.conf has when you're encountering the error?
$ ls -Z /etc/yp.conf

There are probably some SELinux messages in /var/log/messages related to this error. Can you provide them, please?

Comment 5 Dennis Schridde 2012-04-26 13:39:56 UTC
# ls -Z /etc/yp.conf
-rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/yp.conf

# tail /var/log/messages

Apr 26 15:34:10 dumas NET[2892]: /sbin/dhclient-script : updated /etc/resolv.conf
Apr 26 15:34:10 dumas kernel: type=1400 audit(1335447250.324:5): avc:  denied  { rename } for  pid=2900 comm="mv" name="yp.conf" dev=sda2 ino=391693 scontext=unconfined_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
Apr 26 15:34:10 dumas kernel: type=1400 audit(1335447250.400:6): avc:  denied  { write } for  pid=2858 comm="dhclient-script" name="yp.conf" dev=sda2 ino=391693 scontext=unconfined_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
Apr 26 15:34:10 dumas kernel: type=1400 audit(1335447250.400:7): avc:  denied  { write } for  pid=2858 comm="dhclient-script" name="yp.conf" dev=sda2 ino=391693 scontext=unconfined_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
Apr 26 15:34:10 dumas kernel: type=1400 audit(1335447250.401:8): avc:  denied  { append } for  pid=2858 comm="dhclient-script" name="yp.conf" dev=sda2 ino=391693 scontext=unconfined_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
Apr 26 15:34:10 dumas kernel: type=1400 audit(1335447250.401:9): avc:  denied  { append } for  pid=2858 comm="dhclient-script" name="yp.conf" dev=sda2 ino=391693 scontext=unconfined_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file

Comment 6 Honza Horak 2012-04-27 10:59:00 UTC
(In reply to comment #5)
> # ls -Z /etc/yp.conf
> -rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/yp.conf

This is not correct SELinux content, the correct one is:
# ls -Z /etc/yp.conf 
-rw-r--r--. root root system_u:object_r:net_conf_t:s0  /etc/yp.conf

Please, try to fix it by running:
# restorecon /etc/yp.conf

Or if you suspect other files in /etc can have a wrong context as well, fix the whole directory:
# restorecon -r /etc

Did this help?

Comment 7 Dennis Schridde 2012-04-27 14:07:58 UTC
(In reply to comment #6)
> Or if you suspect other files in /etc can have a wrong context as well, fix the
> whole directory:
> # restorecon -r /etc
I ran "fixfiles onboot" on one machine - does that do the same thing?

> Did this help?
Yes, but I do not understand how this happened in the first place, since the system was freshly installed. Since I used the Scientific Linux installer, I assume this does not matter to you and the bugreport can be closed.

Comment 8 Honza Horak 2012-04-27 15:21:10 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Or if you suspect other files in /etc can have a wrong context as well, fix the
> > whole directory:
> > # restorecon -r /etc
> I ran "fixfiles onboot" on one machine - does that do the same thing?

Yes.

> > Did this help?
> Yes, but I do not understand how this happened in the first place, since the
> system was freshly installed. Since I used the Scientific Linux installer, I
> assume this does not matter to you and the bugreport can be closed.

OK, closing.