Bug 597028 - dhclient is failing to set hostname.
dhclient is failing to set hostname.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dhcp (Show other bugs)
6.0
All Linux
low Severity high
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
:
Depends On: 546765
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-27 20:06 EDT by Quentin Barnes
Modified: 2010-06-07 12:01 EDT (History)
0 users

See Also:
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 12:01:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Quentin Barnes 2010-05-27 20:06:56 EDT
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 06:01:47 EDT
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 12:22:00 EDT
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 Product and Program Management 2010-06-07 11:53:57 EDT
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.

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