On my system, dhcpd is run as the 'dhcp' user (non-root). But, the '/var/lib/dhcp' directory (and its contents) were owned by root:root with 644 permissions. So here's what would happen: dhcpd would run for a while (having been started at boot-time or explicitly restarted after it crashed) and would renew a few leases on my network (1 server, 3 workstations ; 3 static ip's, the rest from a pool.) I would see a few of the leases in my '/var/log/everything'. Then, dhcpd would want to write the leases to '/var/lib/dhcp/dhcpd.leases'. Since it didn't have permission, it put an entry in syslog saying, "Can't create new lease file: Permission denied", and it would crash. The obvious workaround was to: # cd /var/lib # chown -R dhcp:dhcp dhcp/ leaving me to wonder why those permissions weren't set up in the first place. Since fixing that, dhcpd has been running for longer than the usual "time to crash", so assume it's working now. Originally I had tried to remerge dhcp, but that didn't fix the problem. (Maybe a remerge wouldn't replace the '/var/lib/dhcp' directory structure?) Reproducible: Always Steps to Reproduce: 1.emerge dhcp 2.look at how '/var/lib/dhcp' is owned by root:root, but dhcpd is run by user 'dhcp' 3.try to let dhcpd renew some leases, and watch it crash? Actual Results: I watched it crash. Expected Results: Not crash. Moo.
running in chroot is not an option for you ?
> running in chroot is not an option for you ? you'll have to excuse my ignorance, but chroot to where? i can't find any directories or files where user 'dhcp' has write access (besides the ones i manually switched). i thought the 'standard' default behavior was to have the lease file in /var/lib/dhcp/ anyway.
*** Bug 27460 has been marked as a duplicate of this bug. ***
Is dhcpd pre-configured to run as the user dhcp? No 'dhcp' user is created during installation or post-installation. I only run dhcpcd (the client daemon) and - even though it runs as root - It still doesn't create the /var/lib/dhcp/dhclient.leases file. :^(
> Is dhcpd pre-configured to run as the user dhcp? No 'dhcp' user is created during installation or post-installation. > >I only run dhcpcd (the client daemon) and - even though it runs as root - It still doesn't create the /var/lib/dhcp/dhclient.leases file. :^( I did nothing special after the emerging dhcp utilities, and I run both dhcpcd and dhcpd on my router. dhcpd runs as the 'dhcp' user, but dhcpcd runs as 'root'. This seems reasonable, given the functions that they perform. I know why my dhcpd was having problems (see the bug desc.), but I dunno why your dhcpcd isn't writing lease files. Although I'll note that my 'dhclient.leases' is empty and owned by dhcp:dhcp, even though it does have a lease right now. No errors anywhere, though.
Actually dhcpd manage to write some leases to the file, I think it crashes when it is about to cleanup the file and create a new one containing the valid leases. Since it just adds leases to the end of the original lease file it needs to clean it up once in a while. At least that is my observation. I did the same thing 'chown dhcp.dhcp /var/lib/dhcp' to fix it and its running flawlessly since.
Ok, reassigning this bug to myself because I maintain this ebuild. Let me follow up on some things here so we can get this into stable. Danny: I checked in a new version which is supposed to set proper perms. Please try it and report back. To chroot, you need to change /etc/conf.d/dhcp to point to the dhcp directory. This directory must be set up properly. To do that you must first make sure dhcp works correctly without chroot, and then you need to run: ebuild /var/db/pkg/net-misc/dhcp*/dhcp*.ebuild config Eric: version 3.0_p2-r1 (currently ~x86) uses the paranoia patch which changes the daemon to run as dhcp. The user is added to the system during the install procedure.
Okay, I'm trying it w/o chroot for now. I'll have to run it for 24-48hrs. to make sure it's working (give it enough time to need to update the file). I completely unmerged both dhcpcd and dhcp(d) since they shared the offending directory (could this have been the problem?). I backedup'd/removed /etc/dhcp/, /etc/dhcpcd/, and /var/lib/dhcp/. Then, I remerged each package, and re-copied by old /etc/dhcp/ and /etc/dhpcd/ _only_ (not /var/lib/dhcp/). I'll keep y'all posted. (Btw, since remerging, they now have separate directories in /var/lib/, namely /var/lib/dhcp/ and /var/lib/dhcpc/. Is that what this is all about or is it just 'cleaner' that way? The latter, I'm thinking.)
(I just realized bugzilla/mozilla doesn't wrap text lines. My bad.) Okay. It's been running for about 36hrs. Have some info: dannyd@alpha /var/lib $ ls -la dhcp/ dhcpc/ dhcp/: total 9 drwxr-xr-x 2 dhcp dhcp 136 Sep 18 21:52 . drwxr-xr-x 15 root root 368 Sep 17 18:58 .. -rw-r--r-- 1 root root 0 Sep 17 18:58 .keep -rw-r--r-- 1 dhcp dhcp 704 Sep 18 21:52 dhcpd.leases -rw-r--r-- 1 dhcp dhcp 941 Sep 18 21:52 dhcpd.leases~ dhcpc/: total 5 drwxr-xr-x 2 root root 80 Sep 17 18:53 . drwxr-xr-x 15 root root 368 Sep 17 18:58 .. -rw-r--r-- 1 root root 469 Sep 17 18:53 dhcpcd-eth1.info dannyd@alpha /var/lib $ ps axuf | grep dhcp root 3669 0.0 0.1 1340 316 ? S Sep17 0:00 /sbin/dhcpcd -R eth1 dhcp 6092 0.0 0.4 2572 992 ? S Sep17 0:00 [dhcpd] So I guess it's going to work now. I have just executed the 'ebuild config' thing to set up the chroot. '/etc/init.d/dhcp restart' looks good with: "Starting chrooted dhcp... [OK]" All permissions/ownerships look the same as before chroot. Rad.
hi, is it possible that there is a bug in the init-script of dhcpd or somewhere else? i just installed dhcp 3.0_p2-r1 on a new server and used my config from the old server which i should replace, but it just died after 1 hour running. first i thought it was grsecurity because of those messages: grsec: From 10.x.x.x: denied hardlink of /var/lib/dhcp/dhcpd.leases (owned by 0.0) to /var/lib/dhcp/dhcpd.leases~ for (dhcpd:3098) UID(1000) EUID(1000), parent (init:1) UID(0) EUID(0) grsec: From 10.x.x.x: signal 11 sent to (dhcpd:3098) UID(1000) EUID(1000), parent (init:1) UID(0) EUID(0) if i manually "chown dhcp:dhcp /var/lib/dhcp/dhcpd.leases" it seems to be fine (though i can only tell in a few hours). if i then restart dhcpd with "/etc/init.d/dhcp restart" the ownership of the dhcpd.leases file is set to root:root again...and then when dhcpd wants to write to it => crash at the moment i'm using a kernel without grsecurity for testing. i'm not using chrooted environment (commented out the CHROOT line in /etc/conf.d/dhcp) because i got problems with logging when chrooted. JG
Danny, thanks for confirming. I'll close this as fixed. JG, it seems entirely a problem with the grsec patch. You may need to relax/adjust your ACLs. If problems persist, open another bug because that is a completely separate issue. Thanks.
Max: My bug relates specically to dhcpcd-1.3.2* (not dhcpd-3.0). (I had originally opened bug 27460 to report this but it was marked as a duplicate of this bug.) I'm still experiencing the same failure to utilize /var/lib/dhcp/client.leases.
I do still have this problem! I'm using net-misc/dhcp-3.0_p2-r2 and my dhcpd is still crashing regulary. I do also have this root:root problem. ProxyLK root # ls -l /var/lib/dhcp/ total 8 -rw-r--r-- 1 root root 1211 Dec 31 14:06 dhcpd.leases -rw-r--r-- 1 dhcp dhcp 1211 Dec 31 13:48 dhcpd.leases~
Reopening.. I'm really lost as to what is happening here. Mine works just fine without any crashes.
I'm the author of the isc-dhcpd paranoia patch (max contacted me). I'm not in charge of the gentoo package. The fact that the dhcpd.leases file is originally created as root is not a problem; these permissions affect file/inode content only, and should not affect directory actions, such as renaming or deleting the file. This is standard unix behavior, and if the grsecurity patch breaks this, it's a problem with the grsecurity patch. Anyone currently experiencing a server lease-write problem should update this ticket with the following: - permissions of /var/lib/dhcp (ls -ld /var/lib/dhcp) - permissions of <chroot>/var/lib/dhcp if you're using chroot - if the owner of either of these directories is root, that's your problem, and you should list the gentoo package revision you're using. - if the owner of these directories is your dhcp user, i'll need the output of strace, detailing the events leading to program abort. You can use: # strace -o <file> -f dhcpd <options> You can attach the entire strace output to this ticket, though you probably shouldn't include it all in the body of your report. If you're experiencing a client (dhcpcd) lease problem, you have a separate issue, and this ticket is not for you.
ProxyLK root # ls -ld /var/lib/dhcp drwxr-xr-x 2 dhcp dhcp 136 Jan 1 23:37 /var/lib/dhcp This is from syslog: Jan 1 14:23:07 ProxyLK grsec: denied hardlink of /var/lib/dhcp/dhcpd.leases (owned by 0.0) to /var/lib/dhcp/dhcpd.leases~ for (dhcpd:6787) UID(1002) EUID(1002), parent (init:1) UID(0) EUID(0) The dhcpd is starting up and is creating the dhcpd.leases as root. After that it switches to user dhcp. After is trys to create the hardlink, which gets denied by grsecurity. Why can't the dhcpd.leases get created as the dhcp user? Anyways, i attached my new init script, which seems to fix the problem. I change the ownership of dhcpd.leases after dhcpd gets started. Cu
Created attachment 22983 [details] updated dhcpd init file
The script you attached introduces a race condition, in which the lease file may not have been created by the time chown is called. As i mentioned, your issue can be considered a problem with the grsecurity patch, or at least its restrictive settings. However, if you wish to account for this behavior in dhcpd anyway, i know that max had been writing an additional patch to change ownership of the original lease file after creation.
Thank you for clearing this Ari, I completely ignored the fact that grsecurity might be the culprit, but now it makes a lot of sense. Do you see any problems with the patch you mention? If not, I'll put it back for folks with grsec. Thanks again.
Hello again. I'm the original reporter from back in the day. While recently upgrading my system (via emerge world), a new version of dhcpd was installed. The original fix worked for a while (i.e. putting "Setting permissions on dhcpd leases file" in the init script). However, after upgrading the (original) problem came back. Right after the server would start. (I'm fairly sure that) the problem is that the permissions on the leases file are being set (via the init script) _before_ the server starts. The server re-chown's it to root:root. My kludge was to stick an additional "Setting permissions on dhcpd leases file . . . again" ebegin right after the server starts in the start() functions (rather than in the check_config() function where it currently resides. Also, I'm not using any grsecurity stuff or chroot stuff. Back when this issue first came up, I can't remember if the fixed init script put the "Setting permissions..." in check_config() or in start(). However, putting it in the latter has worked for me. dannyd
I went ahead and re-added the ebuild with the chown patch. Give it a try please.
Looks good now. No problems so far.
closing the last time, hope so
