Bug 744292 - ownership of /var/lib/dhcpd and the files in it
ownership of /var/lib/dhcpd and the files in it
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-07 15:12 EDT by Jonathan Kamens
Modified: 2011-12-19 12:54 EST (History)
3 users (show)

See Also:
Fixed In Version: dhcp-4.2.3-1.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-24 23:24:02 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)
patch to set CAP_DAC_OVERRIDE during startup (542 bytes, patch)
2011-10-08 21:04 EDT, Jonathan Kamens
no flags Details | Diff

  None (edit)
Description Jonathan Kamens 2011-10-07 15:12:36 EDT
dhcpd has been changed to run as user/group dhcpd.

The folder /var/lib/dhcpd and the files in it are still owned by root in the rpm.

I just got this error from dhcpd in my logs:

dhcpd: Can't create new lease file: Permission denied

I think the ownership in the RPMs needs to be changed.

I also think there needs to be an RPM script that fixes the ownership on upgrade if upgrading from a version before the change to a non-root user.
Comment 1 Jonathan Kamens 2011-10-08 17:29:06 EDT
This much more complicated than I thought.

If the files are owned by dhcpd:dhcpd, then this error happens when dhcpd starts up:

Oct  8 08:10:26 jik2 dhcpd: Can't open /var/lib/dhcpd/dhcpd.leases for append.
Oct  8 08:10:26 jik2 dhcpd[15547]: Can't open /var/lib/dhcpd/dhcpd.leases for append.

This doesn't make any sense to me. If dhcpd is running as root, i.e., it's before it has given up privileges, then it should be able to open the files because root can open anything. If it's running after giving up privileges, then it should still be able to open the files because I've changed the directory and its contents to be owned by dhcpd:dhcpd.

If I change the permissions on the directory and files to be owned by root instead, then dhcpd is able to start up just fine, but it reports this error six hours after starting up:

Oct  8 14:11:22 jik2 dhcpd: Can't create new lease file: Permission denied
Oct  8 14:11:22 jik2 dhcpd[15565]: Can't create new lease file: Permission denied

This makes sense, since like I said the files are owned by root and it's running as dhcpd. But the rpm says they should be owned by root, and if they're owned by dhcpd startup fails as noted above.

Something's broken, although I can't say what.

Note that I have selinux disabled.
Comment 2 Jonathan Kamens 2011-10-08 21:04:36 EDT
Created attachment 527056 [details]
patch to set CAP_DAC_OVERRIDE during startup

Aha. It's because dhcpd is using capabilities. To make it possible for the files to be owned by dhcpd, AND for them to be openable at startup time, you have to retain CAP_DAC_OVERRIDE until you're finish initializing. The attached path does this.

To summarize, if you agree with this fix, you need to (a) apply this patch (or add the CAP_DAC_OVERRIDE to dhcpd.c in the existing capability patch), (b) fix the RPM so that /var/lib/dhcpd and its contents are owned by dhcpd:dhcpd, and (c) put a script in the spec file to update the permissions on the directory and its contents when upgrading from a dhcp version before this change to one with it.
Comment 3 Jiri Popelka 2011-10-09 08:15:28 EDT
To (a): Actually I think we could remove the dhcpd bits from the capabilies patch at all. I had added it there (bug #699713, comment #3) before I discovered that I can use (bug #699713, comment #9) the "paranoia" feature of dhcpd.
I think we don't need to drop capabilies in dhcpd anymore when it runs as ordinary user now.

To (b)&(c): Agree, I'll fix it.
Comment 4 Jiri Popelka 2011-10-09 14:52:29 EDT
Please try http://koji.fedoraproject.org/koji/taskinfo?taskID=3417188
Comment 5 Michael Weidner 2011-10-10 08:13:46 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=3417188 fixes the problem for me, no more "Can't create new lease file: Permission denied" in the logs.
Comment 6 Jiri Popelka 2011-10-10 12:55:41 EDT
Ok, thanks for testing and mainly for the initial investigation.
Comment 7 Fedora Update System 2011-10-20 05:29:40 EDT
dhcp-4.2.3-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/dhcp-4.2.3-1.fc16
Comment 8 Fedora Update System 2011-10-20 18:16:31 EDT
Package dhcp-4.2.3-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dhcp-4.2.3-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14686
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2011-10-24 23:24:02 EDT
dhcp-4.2.3-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Claude Jones 2011-12-16 10:20:48 EST
I too am having this problem. If I run, as root, "dhcpd eth2" I get:
********************************
dhcpd eth2
Internet Systems Consortium DHCP Server 4.2.3-P1
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Listening on LPF/eth2/00:08:54:38:d4:bf/192.168.2.0/24
Sending on   LPF/eth2/00:08:54:38:d4:bf/192.168.2.0/24
Sending on   Socket/fallback/fallback-net
*********************************
DHCPD can be confirmed to be running because machines on my lan can get addresses
But, when I reboot, I get the following in /var/log/messages and attempts to renew IP addresses by machines on the lan fail:
********************************* 
"Can't open /var/lib/dhcpd/dhcpd.leases for append." 
*********************************
My dhcp versions:
*********************************
rpm -qa | grep dhcp
dhcp-libs-4.2.3-4.P1.fc16.x86_64
gadmin-dhcpd-0.4.9-0.1.rhfc12.nr.i686
dhcp-4.2.3-4.P1.fc16.x86_64
dhcp-common-4.2.3-4.P1.fc16.x86_64
Comment 11 Jiri Popelka 2011-12-16 11:43:57 EST
(In reply to comment #10)
> I too am having this problem. If I run, as root, "dhcpd eth2" I get:
> ...
> But, when I reboot, I get the following in /var/log/messages and attempts to
> renew IP addresses by machines on the lan fail:

How do you start dhcpd after the reboot ?
Again with "dhcpd eth2" ?
Or do you have the dhcpd service enabled so it (should) start itself ?

This could happen when you sometimes run dhcpd by hand as in your "dhcpd eth2" example. And sometimes as a service like "service dhcpd restart" or "systemctl restart dhcpd.service".
Because the service runs dhcpd as user:group dhcpd:dhcpd (by adding the "-user dhcpd -group dhcpd" options) and if the /var/lib/dhcpd/dhcpd.leases is owned by root (because dhcpd was previously running as root) then the dhcpd daemon can't write to it.

So one should also add the "-user dhcpd -group dhcpd" options when running dhcpd by hand, i.e. "dhcpd -user dhcpd -group dhcpd eth2" to prevent this problem. Or simply change owner of /var/lib/dhcpd/dhcpd.leases to dhcpd:dhcpd if it's owned by root.
Comment 12 Claude Jones 2011-12-16 14:28:47 EST
I too am having this problem. If I run, as root, "dhcpd eth2" I get:
********************************
dhcpd eth2
Internet Systems Consortium DHCP Server 4.2.3-P1
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Listening on LPF/eth2/00:08:54:38:d4:bf/192.168.2.0/24
Sending on   LPF/eth2/00:08:54:38:d4:bf/192.168.2.0/24
Sending on   Socket/fallback/fallback-net
*********************************
DHCPD can be confirmed to be running because machines on my lan can get addresses
But, when I reboot, I get the following in /var/log/messages and attempts to renew IP addresses by machines on the lan fail:
********************************* 
"Can't open /var/lib/dhcpd/dhcpd.leases for append." 
*********************************
My dhcp versions:
*********************************
rpm -qa | grep dhcp
dhcp-libs-4.2.3-4.P1.fc16.x86_64
gadmin-dhcpd-0.4.9-0.1.rhfc12.nr.i686
dhcp-4.2.3-4.P1.fc16.x86_64
dhcp-common-4.2.3-4.P1.fc16.x86_64
Comment 13 Claude Jones 2011-12-16 14:36:25 EST
Not sure what happened. I logged back in and there was a collision alarm saying someone else was trying to make changes at the same time as I, but, that 'other' person was me... The choices weren't clear and I obviously picked the wrong one, so I apologize for the duplication. Now, as to your suggestion. (In reply to comment #11)
> (In reply to comment #10)
> > I too am having this problem. If I run, as root, "dhcpd eth2" I get:
> > ...
> > But, when I reboot, I get the following in /var/log/messages and attempts to
> > renew IP addresses by machines on the lan fail:
> 
> How do you start dhcpd after the reboot ?
> Again with "dhcpd eth2" ?
> Or do you have the dhcpd service enabled so it (should) start itself ?

I have dhcpd service enabled so it should start itself. If I reboot, it tries to start and then fails with the unable to write message...

> 
> This could happen when you sometimes run dhcpd by hand as in your "dhcpd eth2"
> example. And sometimes as a service like "service dhcpd restart" or "systemctl
> restart dhcpd.service".
> Because the service runs dhcpd as user:group dhcpd:dhcpd (by adding the "-user
> dhcpd -group dhcpd" options) and if the /var/lib/dhcpd/dhcpd.leases is owned by
> root (because dhcpd was previously running as root) then the dhcpd daemon can't
> write to it.
> 
> So one should also add the "-user dhcpd -group dhcpd" options when running
> dhcpd by hand, i.e. "dhcpd -user dhcpd -group dhcpd eth2" to prevent this
> problem. Or simply change owner of /var/lib/dhcpd/dhcpd.leases to dhcpd:dhcpd
> if it's owned by root.

If I'm understanding you clearly, the permissions should be dhcpd:dhcpd - just changed those, and I'm going to try the reboot and report back.
Comment 14 Claude Jones 2011-12-16 15:10:12 EST
On reboot, I discovered that the service was no longer set to autostart. I set that to do so, and rebooted, and this time, all is working. I'm not sure why those permissions on the dhcpd.leases were wrong. I never went in and changed them but changing them from root:root to dhcpd:dhcpd seems to have sorted out the problem.
Comment 15 Jiri Popelka 2011-12-19 04:51:08 EST
(In reply to comment #14)
> I'm not sure why
> those permissions on the dhcpd.leases were wrong. I never went in and changed
> them but changing them from root:root to dhcpd:dhcpd seems to have sorted out
> the problem.

The running dhcpd process creates (and therefore sets the permissions of) the dhcpd.leases.

When you run it with "dhcpd eth2" then the process is running as root:root and therefore the dhcpd.leases file it creates is owned by root:root.
However the service adds "-user dhcpd -group dhcpd" options which makes the dhcpd process running as dhcpd:dhcpd and therefore the dhcpd.leases file it creates is owned by dhcpd:dhcpd. This is new feature added in F16 (bug #699713, comment #9).
Comment 16 Jiri Popelka 2011-12-19 12:54:55 EST
(In reply to comment #11)
> This could happen when you sometimes run dhcpd by hand as in your "dhcpd eth2"
> example. And sometimes as a service like "service dhcpd restart" or "systemctl
> restart dhcpd.service".
> Because the service runs dhcpd as user:group dhcpd:dhcpd (by adding the "-user
> dhcpd -group dhcpd" options) and if the /var/lib/dhcpd/dhcpd.leases is owned by
> root (because dhcpd was previously running as root) then the dhcpd daemon can't
> write to it.

I've improved the dhcpd[6].service files in rawhide to include
ExecStartPre=/bin/chown -R dhcpd:dhcpd /var/lib/dhcpd/
so the service always corrects the ownership of leases files if they are wrong (as a consequence of running dhcpd by hand without specifying -user/-group)
prior to starting dhcpd.

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