Bugzilla Bug 27079

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 an attachment (id=22983) [edit]
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