Summary: | net-misc/dhcp-3.1.2_p1 init.d/dhcpd test incompatible with chroot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arthur Hagen <art-gt> |
Component: | [OLD] Server | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | lance |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | dhcpd-init2-fix.patch |
Description
Arthur Hagen
2009-07-19 16:46:05 UTC
Created attachment 201716 [details, diff]
dhcpd-init2-fix.patch
We encountered the same problem at the OSL when we upgraded dhcpd for the latest GLSA. It looks like the new init script incorrectly deals with chroot'd dhcp setups. I used the same logic from the start section of the script and applied it to the configtest section.
I tested it on both chroot and non-chrooted dhcpd setups and it appears to work properly now. You should fix this ASAP before other people encounter this problem.
Cheers-
While the patch deals with the chroot situation, it still won't work when the master file is on an NFS mount with root_squash (recommended), unless the file is world readable (not recommended). The test runs as root, unlike the dhcpd process which runs as a user, and thus the test fails when root is disallowed from reading the include file. Similar for selinux or file systems with ACLs, I should think. Yeah, you can patch that too by adding -user and -group as appropriate, but what's the point? It doesn't add any value whatsoever, because any errors -t catches are also caught by attempting to start the daemon. If the daemon doesn't start, THEN the script can run -t to (try) to find out why, but if it DOES start, -t only adds to the startup time without giving any benefit. Most distros try to reduce startup time, not increase it. (In reply to comment #2) > While the patch deals with the chroot situation, it still won't work when the > master file is on an NFS mount with root_squash (recommended), unless the > file is world readable (not recommended). The test runs as root, unlike the > dhcpd process which runs as a user, and thus the test fails when root is > disallowed from reading the include file. Similar for selinux or file > systems with ACLs, I should think. > > Yeah, you can patch that too by adding -user and -group as appropriate, but > what's the point? It doesn't add any value whatsoever, because any errors -t > catches are also caught by attempting to start the daemon. If the daemon > doesn't start, THEN the script can run -t to (try) to find out why, but if it > DOES start, -t only adds to the startup time without giving any benefit. > Most distros try to reduce startup time, not increase it. The point is, you don't want to stop a critical service if there's a config syntax error. DHCPD will *not* start if there's a syntax error, so if you test it afterwards your service will be broken. Testing it afterwards is pointless since you would have stopped the process at that point. Doing the check before allows you to keep the service running while you fix the config error. We probably should add -user/-group to the check so that its the same, but I don't know many people who are running DHCP via NFS ;-) ive included this in dhcp-4.2.1. i'll leave open in case someone wants to also add to dhcp-3.x. dhcp-4.x is stable now. dhcp-3.x is dead. |