Feature request: allow forced netavark firewall driver

[oskarirauta]

Feature request description

Netavark for the moment comes with 2 supported variants of firewall, firewalld and iptables; there's also nftables, but if that is enabled, error is thrown that it isn't currently supported. There has been a feature request on netavark for none firewall, meaning possibility to disable all firewall/portmapper related features to allow their management either manually, possibly with firewall that is not supported by netavark - or not to do it at all, if that's what user wants.

Currently iptables is more or less considered as old- modern distros that don't use firewalld, often go with nftables- in my case, I want to run podman on Openwrt, which goes to later mentioned, except that, I want to configure my firewall manually, whether I use iptables or nftables, there is a small issue; when ever any interface renews, firewall is restarted, leading to situation where manually written rules (outside of system specified ways), disappear for good. Let's say, that my netavark interface is podman0, it comes up and firewall rules are written, shortly after this hotplug system triggers firewall restarting and my container(s) loose all their firewalling capabilities. Best solution in this case, is to use system's own firewalling method manually, there's some ways to archieve this, but it would be great if this just could be a configurable option. Ackording to chatter about the subject, this doesn't affect only openwrt, feature is looked up by other os users as well.

Suggest potential solution

Feature currently is unsupported by netavark, but in progress. I actually wrote a fork that does support this, but name of value for environment variable should be debated by netavark maintainers- and check if they'd be interested in changing some things, even though my patch does seem to do exactly the requested; as they proposed it.

Usage of feature is by exposing a environment variable for netavark, called NETAVARK_FW - supported values are "firewalld", "iptables", "nftables" where last one causes error mentioned before - and in my patch, value is added to list as "none", meaning to disable firewall features completely by stub firewall driver;

containers/netavark#339 (comment) explains proposing usage solution for this, value in containers.conf for selecting disabled firewall which then would trigger NETAVARK_FW environment variable adding to netavark commands environment.

So could we have a configuration option to containers.conf that passes NETAVARK_FW as environment variable when netavark is executed? Maybe like this
firewall_driver = 'your_choice_of_forced_driver'
where value would be passed as NETAVARK_FW environment value if value pair is present in containers.conf.

Have you considered any alternatives?

At the moment, this is do-able with sticking to cni...
Or you could choose a legacy iptables- or change your distribution to something that uses firewalld..

Additional context

https://github.com/containers/netavark/issues/339](https://github.com/containers/netavark/issues/339

[Luap99]

+1 to firewall_driver as option name, it should be added under the [network] section. We can then pass this down to netavark via the NETAVARK_FW env var.

[unknowndevQwQ]

+1 to firewall_driver as option name, it should be added under the [network] section. We can then pass this down to netavark via the NETAVARK_FW env var.

Personally, I suggest changing firewall_driver to packetfilter_backend or packetfilter_controller, and adding the parameter --pf-backend/--pf-controller <firewalld/iptables/nft> to the incoming method, which is not a way to deprecate getting the backend through environment variables

[unknowndevQwQ]

Also, I would like to ask a question here: what is the basis for netavark's priority of using firewalld/iptables/nft? Does it try to check that the dbus bus has firewalld before using ipt/nft? (cni-plugins will check for the presence of firewalld before using iptables)

[oskarirauta]

@unknowndevQwQ

netavark does not support nft yet, if you try to activate it, you receive error that it isn't yet supported.
Same source also mentions that firewalld is not supported fully.

But yes, for the moment; available supported arguments are:

• firewalld
• iptables
• nftables
• none

Feature is already done like this, so it's unlikely to be available in that form as driver option should be carried from main to mod when env is available globally- not impossible, but unlikely to happen, I think..

@Luap99 though decides on things like that..

Also, I would like to ask a question here: what is the basis for netavark's priority of using firewalld/iptables/nft? Does it try to check that the dbus bus has firewalld before using ipt/nft? (cni-plugins will check for the presence of firewalld before using iptables)

Thank god that it doesn't do so and depend on such monster as dbus :O
For the moment, iptables if preferred as a hard-coded option.

I would make a PR to this, but Go isn't my strong suite.. I could do it, but it would be nasty. I think here, a surgeon would be preferred over a lumber jack.. But surely this could be done nicely by someone else.

[unknowndevQwQ]

Feature is already done like this, so it's unlikely to be available in that form as driver option should be carried from main to mod when env is available globally- not impossible, but unlikely to happen, I think..

@oskarirauta Wait, what function is meant by function here?

[oskarirauta]

@unknowndevQwQ
Function? I assume you wanted to say feature, otherwise I am not quite sure what you are asking.
Feature: firewall driver selection. It already is in netavark. Selection is done with setting desired choise to NETAVARK_FW environment variable.

Like this for example:
root@test:/localhost# NETAVARK_FW=firewalld /usr/lib/podman/netavark

[unknowndevQwQ]

Function? I assume you wanted to say feature, otherwise I am not quite sure what you are asking. Feature: firewall driver selection. It already is in netavark. Selection is done with setting desired choise to NETAVARK_FW environment variable.

@oskarirauta
Can it now also be changed to be passed through parameters instead of environment variables?

[oskarirauta]

@unknowndevQwQ

No, just like I earlierly told you. Firewall driver selection is made inside a function that has no access to command-line arguments (as far as I know, I am not a rust expert) where as ENV is available globally. Most likely that would need to be parsed on startup (main in c/c++) of application, and then passed through all the functions all the way to mod.rs which then is handling selection of firewall driver, possibly even would be integrated in some classes, sorry; I didn't investigate any further, how long would the path go; I think that this is one of the main reasons, why it rather uses env.

Firewall selection isn't my hand-writing at all, I just added there one more option: disable firewall completely. You could request such feature from Luap99 on netavark repository, but in my opinion, which doesn't weight, but still- such feature is unlikely to happen, as it would fundamently change design and as I described, it's very likely that it would have a lot of changes to netavark. Not sure if this request is fulfilled here anytime soon, but also, NETAVARK_FW could be passed every time, when netavark is invoked, with argument set or unset in containers.conf - as passing it with empty argument, would be same as not passing it at all. Where as command-line argument, would have other difficulties, for example:

./my-program --arg1 123 --arg2 456
Which would be right way, to use my-program, and then:
./my-program --arg1 --arg2 456
would need more programming to realize that --arg2 isn't value set for arg1, unless there's a mess, as you see, next it would think of 456 as a new arg.. See my logic here? It's not impossible, it's quite common logic, just check that arg after --arg1 or --arg2 is valid, etc- but as you see, it's a lot of extra work, unless you by yourself make a PR, that handless passing of command-line arguments on netavark, all the way to mod.rs, and that logic is smart; it's very unlikely to happen. There might also be some more hickups on the way, that I didn't cover up here. Ther might be either be rust design or netavark's code specific. Yet if you make the PR, it might be un-accepted due to unnecessary change or whatever, but consult Luap99 like I said, and do it on the netavark repository. As a feature request or as a follow up on similar PRs or on a similar issue.

Maybe it also could be very easy. Like I said, I don't know rust that much.

But.. May I ask you why this would be important? Out of my curiosity.

[oskarirauta]

For those who are in haste to force firewall driver on the early train, I'll provide a method of wrapper-script. In here, I assume your netavark lives in /usr/lib/podman..

Rename your netavark to netavark-bin and write a script with filename netavark to same location and set executable bit, enter following content to script:

#!/bin/sh
NETAVARK_FW="none" /usr/lib/podman/netavark-bin $@

Replace none between quotes with your choice of firewall. But for proper support, I hope it will soon be provided from containers.conf

[unknowndevQwQ]

No, just like I earlierly told you. Firewall driver selection is made inside a function that has no access to command-line arguments (as far as I know, I am not a rust expert) where as ENV is available globally. Most likely that would need to be parsed on startup (main in c/c++) of application, and then passed through all the functions all the way to mod.rs which then is handling selection of firewall driver, possibly even would be integrated in some classes, sorry; I didn't investigate any further, how long would the path go; I think that this is one of the main reasons, why it rather uses env.

Firewall selection isn't my hand-writing at all, I just added there one more option: disable firewall completely. You could request such feature from Luap99 on netavark repository, but in my opinion, which doesn't weight, but still- such feature is unlikely to happen, as it would fundamently change design and as I described, it's very likely that it would have a lot of changes to netavark. Not sure if this request is fulfilled here anytime soon, but also, NETAVARK_FW could be passed every time, when netavark is invoked, with argument set or unset in containers.conf - as passing it with empty argument, would be same as not passing it at all. Where as command-line argument, would have other difficulties, for example:

./my-program --arg1 123 --arg2 456 Which would be right way, to use my-program, and then: ./my-program --arg1 --arg2 456 would need more programming to realize that --arg2 isn't value set for arg1, unless there's a mess, as you see, next it would think of 456 as a new arg.. See my logic here? It's not impossible, it's quite common logic, just check that arg after --arg1 or --arg2 is valid, etc- but as you see, it's a lot of extra work, unless you by yourself make a PR, that handless passing of command-line arguments on netavark, all the way to mod.rs, and that logic is smart; it's very unlikely to happen. There might also be some more hickups on the way, that I didn't cover up here. Ther might be either be rust design or netavark's code specific. Yet if you make the PR, it might be un-accepted due to unnecessary change or whatever, but consult Luap99 like I said, and do it on the netavark repository. As a feature request or as a follow up on similar PRs or on a similar issue.

Maybe it also could be very easy. Like I said, I don't know rust that much.

@oskarirauta
I just noticed that you are not the one in charge of this featrue, sorry.

With the help of the clap-like args parser in rust, it does become easier to do something like this. I should create an issue in netavark and continue to discuss the issues I raised above.

But.. May I ask you why this would be important? Out of my curiosity.

Environment variables can be a hindrance in checking for problems because they are not as visible as the command line is in ps or other tools. I had tried to get podman to use gvisor as the OCI runtime, but kept having problems until I found out that podman was misbehaving (podman was passing an empty XDG_RUNTIME_DIR to gvisor).

[unknowndevQwQ]

Selecting the backend by environment variables is provided in this commit.

[oskarirauta]

@unknowndevQwQ

env is always available at proc.. /proc/{pid}/env

[oskarirauta]

Yes, but that seems to be quite old commit.. Check present mod.rs instead.

[fansari]

For those who are in haste to force firewall driver on the early train, I'll provide a method of wrapper-script. In here, I assume your netavark lives in /usr/lib/podman..

Rename your netavark to netavark-bin and write a script with filename netavark to same location and set executable bit, enter following content to script:

#!/bin/sh
NETAVARK_FW="none" /usr/lib/podman/netavark-bin $@

Replace none between quotes with your choice of firewall. But for proper support, I hope it will soon be provided from containers.conf

This is not possilbe for os-tree systems like Fedora Core OS where the /usr tree is immutable.

[rtgiskard]

I think the better solution would be config based network setup just like cni plugins

[anagno]

Do we know in which release the e8d080d commit will be integrated ?
Currently it is in main, but not in the v0.57 branch, so it is not being included in Podman.

[Luap99]

podman 5.0

[yol]

This is not possilbe for os-tree systems like Fedora Core OS where the /usr tree is immutable.

You can do the modification in another directory and list that directory in helper_binaries_dir in containers.conf. If /usr/local is writable, you can just place the file in /usr/local/lib/podman.