upvote
> It's interesting that systemd is mentioned there, because a socket unit would have had systemd doing the privileged opening of the sockets with low-numbered UDP ports, and the dropping of privileges, before starting up Kea.

Can systemd give you the raw sockets you need to answer DHCP on a local network?

One rather annoying thing that ISC dhcpd couldn't do was reload its config file without a full restart (and I believe Kea can). That's pretty hard to do if you insist on someone else opening sockets for you, although you could of course demand a restart in this case.

TBH my problem (well, one of my problems) with Kea is more that it's _too_ many different daemons that you have to configure separately and get to talk to each other, and it's not immediately obvious if any given configuration is secure or not (e.g., can others open a socket of the same name?).

reply
> Instead, its documented approach to running as some other account is to add some of the superuser's privileges to Kea [...]

Not disagreeing, just want to mention that Kea can run fine without privileges, which is also documented at the link provided. Key is to use DHCP relaying, a technique which becomes relevant quickly in larger setups anyways because you cannot (or don't want to) give the DHCP server access to all subnets: Instead of the DHCP server(s) processing local requests, DHCP relaying agents encapsulate and unicast-forward the whole DHCP request-response traffic to centralized DHCP instance(s). Those relaying agents (on switches/routers) do require privileges but potentially posing a smaller attack surface due to being much simpler. Sadly, ISC has not made a successor dhcprelay as part of Kea, but luckily systemd-networkd implements the RelayTarget parameter, adding this capability (at least for IPv4).

reply
Does systemd socket activation even work with broadcast packets? One of the things a dhcp server needs to do is respond to DHCPDISCOVER packets, which are sent to the all-broadcast 255.255.255.255 .
reply
There's nothing stopping it. systemd doesn't do anything particularly special when opening a datagram socket that magically prevents it from receiving broadcast datagrams. There's no difference between Kea opening the socket and systemd opening the socket, except that systemd can do it and then drop privileges before Kea is loaded and run.

Or could do it.

If it weren't that Kea has no mechanism for taking and just using an already-open socket.

Remember that Accept in a socket unit has no meaning for ListenDatagram sockets. There's no waiting for incoming connections before activation going on.

If you're asking about the detailed internals of what systemd does with BPF and how that meshes with what Kea does, then I leave that to be answered by the systemd and Kea people. (-:

reply