Bug 201789

Summary: xt_cgroup checks for cgroup2 existence on rule addition but a cgroup used within an existing rule can be destroyed
Product: Networking Reporter: Louis Sautier (sautier.louis)
Component: Netfilter/IptablesAssignee: networking_netfilter-iptables (networking_netfilter-iptables)
Status: NEW ---    
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.19.4 Subsystem:
Regression: No Bisected commit-id:

Description Louis Sautier 2018-11-26 22:56:52 UTC 
Hi,
I've been trying to use iptables with "-m cgroup --path" and I noticed that it requires the cgroup to exist.
On the other hand, once the rule has been added, the cgroup can be destroyed. This can cause weird issues like not being able to add anything to the related table. For instance, the following snippet fails and it's not easy to understand why since we're trying to add a perfectly valid rule (possibly a long time after the cgroup was destroyed):
# cd /sys/fs/cgroup/unified
# mkdir test
# iptables -A OUTPUT -m cgroup --path test -j ACCEPT
# rmdir test
# iptables -A OUTPUT -j ACCEPT
iptables: Invalid argument. Run `dmesg' for more information.
# dmesg | tail -n1
xt_cgroup: invalid path, errno=-2

Could we prevent the cgroup from being destroyed while a related rule exists?

On a slightly related note, I find that the requirement to have an existing group  when creating a rule is a bit restrictive, it makes it impossible for me to write static rules that rely on the cgroups that systemd or OpenRC create because I have no guarantee that the cgroup will exist when my system loads the netfilter rules (which should be before starting most services).
I understand that it's currently impossible to create the rule before the cgroup because cgroup_get_from_path is called on rule addition. However, it would be nice if a future version of the xt_cgroup module could support truly static netfilter rules which only rely on cgroup names.
Until this is possible, I'll have to stick to v1 cgroups and their numeric classids which are less descriptive but more lenient.