Permissions spec & Neutron driver

[James Beedy]

Hello,

I am implementing an ISC DHCP server driver for the Openstack Neutron project. My goal is to create a python module that controls, and allows multiple instances of ISC DHCP server to run under multiple different users. It would be nice if there was a spec that detailed the constraints concerning permissions of groups, users, directories and files associated with the ISC DHCP server....as of right now I am playing a lot of guess and check, hopefully this is something you might be able to shed some light on. I am currently experimenting with running different instances of ISC DHCP server each in a chroot environment, but would like to not have to create a separate container or chroot for each instance of ISC DHCP server running on a box. I’m sure there is a more efficient way, I just am unfamiliar with the permissions spec. Any insight to the permissions associated with ISC DHCP server would be extremely appreciated. Also, is an ISC DHCP neutron driver something the ISC team has thought about, or possibly already has in the works somewhere? 

Thanks in advance for your insight,

James

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

James Beedy <[hidden email]> wrote:

> I am implementing an ISC DHCP server driver for the Openstack Neutron project. My goal is to create a python module that controls, and allows multiple instances of ISC DHCP server to run under multiple different users. It would be nice if there was a spec that detailed the constraints concerning permissions of groups, users, directories and files associated with the ISC DHCP server....as of right now I am playing a lot of guess and check, hopefully this is something you might be able to shed some light on. I am currently experimenting with running different instances of ISC DHCP server each in a chroot environment, but would like to not have to create a separate container or chroot for each instance of ISC DHCP server running on a box. I’m sure there is a more efficient way, I just am unfamiliar with the permissions spec. Any insight to the permissions associated with ISC DHCP server would be extremely appreciated.

With the caveat that I'm neither a programmer nor an expert in this area ...
I think you'll find that the server really doesn't need many permissions at all. With one exception, it needs to be able to read it's config file, write it's PID file, and write/re-write it's lease file - with all that, it doesn't need any privileged access to anything (so basically the appropriate read & write permissions to the files/directories it needs to work in).

What it does need is the ability to handle raw sockets. So it needs to be able to take packets off the wire which can't be handled by the IP stack, and send packets directly which can't be sent via the IP stack. This is probably the only privileged access it needs.

The other issue is that you can only run one instance per interface, and there are some reports that it doesn't "play nice" with VLANs. I'm not sure of the details, but IIRC when it's come up, there have been issues of tagged packets being picked up by a server listening on an untagged interface of a trunked port.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Tomek Mrugalski]

On 15.07.2015 17:42, James Beedy wrote:
> I am implementing an ISC DHCP server driver for the Openstack Neutron
> project. My goal is to create a python module that controls, and allows
> multiple instances of ISC DHCP server to run under multiple different
> users. It would be nice if there was a spec that detailed the
Have you looked at Kea (http://kea.isc.org), ISC's new DHCP
implementation? While it is not yet as feature rich as the dhcpd, it has
a number of advantages that may be more useful for your purpose:

1. Kea allows on-line reconfiguration. You can update configuration
without shutting down the server.
2. The configuration file in JSON format. Processing JSON structures in
python should be straightforward. It should be much easier to generate
your configuration.
3. While Kea uses raw sockets by default, you can configure it to use
UDP sockets. That works well if all your traffic is coming through relay
agents. There are certain caveats, but this is something you may
investigate.
4. I do not know OpenStack infrastructure, but the only code that
requires root access is socket opening. This part of the code is nicely
structured to support different types of operation. We have regular UDP
sockets and specific implementations for LPF (Linux) and BPF (BSD
family). It should be relatively straightforward to implement something
else specific for OpenStack, if needed.
5. Kea's development is much faster, due to number of reasons: open
development (we have git repo on github), better code structure, lots of
unit-tests (2900+ and growing), good documentation (both user and
developer oriented) and also using modern techniques (C++, boost, tdd, ci).
6. Better performance. Want to hand out 7500 leases/sec? Sure.
7. Hooks. Do you want the server to do something unique? Have your own
lib do the magic trick.
8. Want to use CSV file to store your data? How about MySQL or Postgres?
Or maybe your own special database?

> files associated with the ISC DHCP server....as of right now I am
> playing a lot of guess and check, hopefully this is something you might
> be able to shed some light on. I am currently experimenting with running
> different instances of ISC DHCP server each in a chroot environment, but
> would like to not have to create a separate container or chroot for each
> instance of ISC DHCP server running on a box. I’m sure there is a more
> efficient way, I just am unfamiliar with the permissions spec. Any
> insight to the permissions associated with ISC DHCP server would be
> extremely appreciated. Also, is an ISC DHCP neutron driver something the
> ISC team has thought about, or possibly already has in the works somewhere?

I can't speak for the ISC DHCP team, but as a Kea developer, I can tell
you about the situation in this project. We haven't actively worked on
OpenStack, simply because of time constraints. However, we'd love to see
the OpenStack support. We're warming up for our upcoming 1.0 release and
have our roadmap pretty must set for the next couple months. While it's
unlikely that we could develop anything major on our own, but we
definitely can review patches if you care to send any. We could also
give you some pointers, give tips or suggest various tricks.

On a related note, I just successfully run kea-dhcp4 (and kea-dhcp6,
too, if you care for IPv6) from regular account. For testing purposes,
kea can be told to listen on different than the regular, privileged
port. I told it to use UDP sockets ("dhcp-socket-type": "udp") and
listen on port 50000 (-p 50000 on command line). It's not really usable
in such mode (unless you reconfigure your relays to send traffic to
custom port), but it shows that opening sockets is the only major issue
that has to be solved and there should be no other gotchas.

If you're interested in this direction, let's continue this conversation
on the kea-dev mailing list
(https://lists.isc.org/mailman/listinfo/kea-dev).

Hope that helps.

Tomek Mrugalski
Kea developer, ISC

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users