Bug 744292

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.

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.

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.

Please try http://koji.fedoraproject.org/koji/taskinfo?taskID=3417188

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.

Ok, thanks for testing and mainly for the initial investigation.

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

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).

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.

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

(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.

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

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.

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.

(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).

(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.