Bug 597028

Summary:	dhclient is failing to set hostname.
Product:	Red Hat Enterprise Linux 6	Reporter:	Quentin Barnes <qbarnes>
Component:	dhcp	Assignee:	Jiri Popelka <jpopelka>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	high	Docs Contact:
Priority:	low
Version:	6.0
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	dhclient-4.1.1-2.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-06-07 16:01:54 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:
Bug Depends On:	546765
Bug Blocks:

Description Quentin Barnes 2010-05-28 00:06:56 UTC

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.

Comment 2 Jiri Popelka 2010-05-28 10:01:47 UTC

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

Comment 3 Quentin Barnes 2010-05-28 16:22:00 UTC

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 4 RHEL 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.