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.
Description of problem:
dhclient is failing to set hostname.
Version-Release number of selected component (if applicable):
dhclient-4.1.0p1-15.el6.x86_64
How reproducible:
100%
Steps to Reproduce:
1. As root, run "dhclient -d -v" and see the message "hostname: you must be root to change the host name" and notice the hostname has not changed
2.
3.
Actual results:
============
# dhclient -d -v
Internet Systems Consortium DHCP Client 4.1.0p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
[...]
DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 3
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.74.90.3
hostname: you must be root to change the host name
bound to 10.74.90.165 -- renewal in 3000 seconds.
[...]
============
Expected results:
Hostname is updated.
Additional info:
I straced the command and I think I know what the problem is. First,
the failure comes from:
============
3183 execve("/sbin/dhclient", ["dhclient", "-d", "-v"], [/* 22 vars */]) = 0
[...]
3183 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f797e9fb9f0) = 3198
[...]
3198 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ffd5e0d99d0) = 3235
[...]
3235 sethostname("enemycanmeet.champ.corp.yahoo.com", 33) = -1 EPERM (Operation not permitted)
============
What I think is going on is that sethostname(2) requires CAP_SYS_ADMIN,
however, earlier, dhclient process did:
============
3183 capset(0x20080522, 3183, {CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0
============
Which gave up its CAP_SYS_ADMIN capability.
As part of the lowering capabilities project
(http://fedoraproject.org/wiki/Features/LowerProcessCapabilities)
all unnecessary capabilities in dhclient are dropped.
In dhclient-4.1.1-2.el6 is new -nc option and dhclient(8) man page documents it this way:
"
-nc Do not drop capabilities.
Normally, if dhclient was compiled with libcap-ng support, dhclient drops most capabilities immediately upon startup. While more secure, this greatly restricts the additional actions that hooks in dhclient-script (8) can take. (For example, any daemons that dhclient-script (8) starts or restarts will inherit the restricted capabilities as well, which may interfere with their correct operation.) Thus, the -nc option can be used to prevent dhclient from dropping capabilities.
"
With dhclient-4.1.1-2.el6 or newer you can run "dhclient -d -v -nc" or
put line
DHCLIENTARGS=-nc
in (e.g.) /etc/sysconfig/network-scripts/ifcfg-eth0
Yet it's still not a perfect solution.
Additional info:
Bug #546765
Thanks for the hackaround. I'll give it a try.
This is my first of unfortunately many RHEL6 Beta bug reports. When I looked for already filed related bugs, I didn't think of searching Fedora. Sigh. I'll know from now on.
As you said, "...all unnecessary capabilities...". Unnecessary is fine, but the problem is that CAP_SYS_ADMIN is definitely necessary for the sethostname(2) call.
Comment 4RHEL Program Management
2010-06-07 15:53:57 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
inclusion.