[systemd-devel] nftables

[Daniel Mack]

Hi Daniel,

On 02/22/2016 11:04 AM, Daniel Wagner wrote:
> On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:

>> I haven't been following the recent (well... the last ~2 years ^^')
>> work on nftables but I believe there are still people using the
>> iptables format. The use the iptables- nftables compatible tool, and
>> it mimics iptables through nftables. Verify it, but if it's the
>> generic way, then it would be as usual in ConnMan.

It aims for that, yes, but in my tests there were quite some uncovered
corner cases when it comes to command line compatibility. But I wonder
why this is related to ConnMan - does it call out to the binary?

>> If not, then you will have to come with a strategy that fits all. And
>> that's when it
>> might become tricky. As you noticed, ConnMan will have to avoid conflicts.

I haven't followed the discussions. What kind of conflicts is this about?

>> I believe it will be a bit easier than with iptables though.
>> - you pull the current context:
>>   -> if there is nothing, it will be easy ConnMan will just push
>> whatever it will want.
>>   -> if something is there, integrating will have to play nice.
>> Basically: finding the
>>     input entry point to jump on a custom ConnMan table (you'll probably
>> need that
>>     for each IP version), get you rules applied or return if nothing.

IMO, ConnMan, or any other tool for that matter, should never mess with
rules it hasn't created itself. nftables makes this easy, as it allows
for namespaces in the rule sets, through custom tables. If any other
tool installs other tables with conflicting rules, I don't think ConnMan
should care really. With iptables, this is just a bit trickier due to
the custom jump label that you have to install in the INPUT and OUTPUT
chains.

Right now, there are two parts of systemd that touch packet filter
configurations, nspawn and networkd, and the code already takes care of
not touching any rule that it has no business with.

> Lennart posted the headsup on systemd moving from iptables to
> nftables [1]. I don't know how far those plans have gotten but I think
> it would be good idea to coordinate this with systemd-networkd.
> 
> @Tom do you happen to know what the status is on this?

It was me who worked on this, and I postponed the branch a while ago
until we know how the kernel APIs look like that we want to use for a
per-unit packet filtering mechanism. Back then, it looked like this
could only be achieved with nftables, which is why I reworked all the
code in systemd.

Now, things are not that clear anymore, so the decision was postponed. I
hope to catch up with this soon, but eventually, I think we should move
to nftables as well. Note, however, that iptables and nftables may
coexist on a system.

>> About coding around, it's a bit messy. There is one library,
>> libnftnl. It's not build on top of libnl. I am not entirely sure, but
>> I think you can hook your own netlink access functions to it. By
>> default it uses libmnl... You'll have to verify that. Ask Marcel what
>> he would prefer as well. Afaik, there is still the plan to move 
>> ConnMan to ell, so keeping it's custom netlink access would make
>> sense then, I guess.
> 
> I really like to avoid coding directly netlink. The libnftnl doesn't look
> too bad. 

You can have a look at the outdated branch of mine here:

  https://github.com/zonque/systemd/commits/nftnl



HTH,
Daniel