Recognize the absent-chain message both iptables backends emit - #863
Open
Darren Hoehna (dhoehna) wants to merge 1 commit into
Open
Recognize the absent-chain message both iptables backends emit#863Darren Hoehna (dhoehna) wants to merge 1 commit into
Darren Hoehna (dhoehna) wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Updates LXC ingress firewall teardown so fresh-container resets tolerate absent-chain diagnostics from both iptables backends.
Changes:
- Recognizes
nf_tablesand legacy absent-chain messages. - Adds regression coverage using captured iptables 1.8.10 diagnostics.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Inbound default-deny could not be installed on any host whose iptables defaults to the nf_tables backend, which is Ubuntu, Debian, RHEL, and Alpine among others. Every run failed with: inbound teardown for chain 'MXCI-<name>' failed: nsenter -t <pid> -n iptables -D INPUT -j MXCI-<name> failed: iptables v1.8.10 (nf_tables): Chain 'MXCI-<name>' does not exist Installing the chain first resets any leftover state, and that reset unhooks before it flushes and deletes. On a freshly started container the chain has never existed, so the unhook is expected to fail and `stderr_means_absent` is what turns that benign failure into a no-op. It only recognized the legacy wording. Captured from iptables 1.8.10 under `LC_ALL=C`, the two backends disagree only on this one step: unhook, chain absent nf_tables Chain 'X' does not exist unhook, chain absent legacy Couldn't load target `X':No such ... flush/delete, absent both No chain/target/match by that name. So flush and delete were already covered and unhook never was, which is why the failure reproduced on every install rather than intermittently. Match both spellings, for every step, since "does not exist" means the same thing wherever it appears. The bare spawn-failure string "No such file or directory" still must not count as proof the chain is gone, so the legacy form is matched on "couldn't load target" instead. Verified by running tests/scripts/run_lxc_inbound_deny_test.sh against real LXC containers on Ubuntu 24.04 under WSL 2 (LXC 5.0.3, iptables 1.8.10 nf_tables). Before: FAIL on the default-deny case. After: both cases pass, including the workload executing inside the container. The added test fails if the classifier change is reverted. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9d686207-0b76-4f46-8850-1bcab2531161
Darren Hoehna (dhoehna)
force-pushed
the
user/dahoehna/lxc-ingress-nft-absent-chain
branch
from
August 14, 2026 04:13
5dd2cba to
db942db
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Inbound default-deny could not install on any host whose
iptablesuses thenf_tables backend — the default on Ubuntu, Debian, RHEL, and Alpine. It failed
on every install, not intermittently:
Install resets leftover state first, and that reset unhooks before it flushes and
deletes. A fresh container has never had the chain, so the unhook is expected
to fail —
stderr_means_absentis what makes that benign. It matched only thelegacy wording, so the reset failed fatally and aborted the install.
Fix
Recognize the absent-chain message from both backends. Strings captured from
iptables 1.8.10 under
LC_ALL=C:Chain 'X' does not existCouldn't load target `X':...No chain/target/match by that name.Legacy is matched on
couldn't load target, so a bareNo such file or directoryspawn failure still does not count as proof the chain is gone.Verification
tests/scripts/run_lxc_inbound_deny_test.shagainst real LXC containers(Ubuntu 24.04 on WSL 2, LXC 5.0.3): FAIL before, both cases PASS after. The
added unit test fails if the fix is reverted.
🔗 References
Relates to AB#62864412
Follow-up to #836