Le mardi 19 janvier 2021 à 11:20:41+0100, Ludwig Gramberg a écrit : > Hi Pierre-Elliot, > > it’s not that you lose rules set by lxc-net, you basically have a > race-condition. > > lxc-net is setting rules directly by calling iptables commands, > setting one rule at a time. iptables-persistent on the other hand is > using the iptables-restore command and these don’t mix. If anyone is > setting rules in iptables while the restore-command is running the > restore-command fails. > > So it is not about overwriting each other its about the restore > failing entirely. I would be happy if the restore „would win“ but it > utterly fails leaving the server without its most important basic set > of firewall-rules. This is why I categorized this as severe.
IMHO your choice of severity was too strong. This is an incompatibility between two packages that poses some security concerns, but it's not a CVE, an it's not a daily case for everyone. I'm eager to tackle it without putting an unneeded Conflicts/Breaks: entry on lxc, but it remains something a system administrator has to handle and check when one installs such programs. > The problem can happen with any combination where a process sets > firewall rules early in the boot-process while netfilter-persistent is > doing its restore. So actually the good solution would be for netfilter-persistent to be fully started *before* lxc-net tries to start, am I right? We could probably try to do that with systemd files. > Last I have seen this in Debian 9 happening and have not yet tested > this in Debian 10 (doesn't Deb10 use nftables which is profoundly > different?) Both alternatives are present on Debian 10 (iptables and nftables). -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
