On Thu, 30 Jun 2022, Daniel Gröber wrote:
You also consider that using absolute path in includes is suboptimal?
Ok so what I want to do is load an about to be deployed nftables config
without making it permanent yet as it might be buggy and cause an ssh
lockout. To prevent this I first load the temporary config with `nft -f`,
check ssh still works and only then commit the config to the final location
in /etc.
This works all fine and dandy when only one nftables.conf file is involved,
but as soon as I have includes I need to deploy the entire config directory
tree somewhere out-of-the-way.
We're probably getting a little off topic for netfilter-devel, but
could you do this using a mount namespace? For example (as root, since
you indicated that you want to really load the actual ruleset into the
main firewall):
Set up the nft config to test:
root@nftest /tmp# mkdir -p nft-test/etc/nft.d
root@nftest /tmp# cat > nft-test/etc/nft.conf <<<'include "/etc/nft.d/nft.included.conf"'
root@nftest /tmp# cat > nft-test/etc/nft.d/nft.included.conf <<<$'flush ruleset\ncreate table inet filter'
Set up a temporary separate mount namespace. Here, this launches a new
shell, so if you're automating this, the rest of the commands need to
be in a separate script, and unshare can invoke that script instead of
an interactive shell:
root@nftest /tmp# unshare --mount
Set up the "fake" /etc to allow the absolute paths to work. This could
probably also be done with an overlay mount if you need to preserve
visibility of the underlying files in /etc, but it's a little more
complicated and probably not necessary.
root@nftest /tmp# mount -o bind nft-test/etc /etc
root@nftest /tmp# ls -l /etc
total 4
-rw-r--r-- 1 0 0 39 Jul 1 00:02 nft.conf
drwxr-xr-x 2 0 0 60 Jul 1 00:02 nft.d/
Now you can load the ruleset fully using absolute paths, even though
the files are stored somewhere else:
root@nftest /tmp# nft flush ruleset
root@nftest /tmp# nft -f /etc/nft.conf
root@nftest /tmp# nft list ruleset
table inet filter {
}
--
Peter Tirsek
