Debian's default firewall is nftables, and the catalogue has no nftables vocabulary

[vladimirrott]

Cross-references corrected 2026-09-14 at 61b3a878. Three issues this body
pointed at have since closed (#234, #237, #238), and one of them changed the
premise rather than the detail: Debian is eligible now, so the first paragraph
below was written in the conditional and should not have stayed there. The
defect itself is unchanged and still reproduces:

$ git rev-parse --short=8 HEAD
61b3a878
$ grep -c Ufw crates/sysknife-types/src/lib.rs
8
$ grep -ci nft crates/sysknife-types/src/lib.rs
0

Scope 1 is taken. PR #413 by @QinXi-ai is open against the read-only half
(GetNftablesRuleset and a backend reporter). Scope 2 is untouched.

The catalogue has eight ufw actions and no nftables ones. On Ubuntu that is the right call, because ufw is the family's canonical frontend. On Debian it is not: Debian's own handbook names nftables as "the default firewall framework in Debian Buster and later", and stock Debian installs no ufw.

Debian eligibility landed on 10 September. #238 is closed and is_supported now accepts Debian 12 and later, so SysKnife already runs on hosts where its only firewall vocabulary is absent.

The two failure shapes

ufw absent. UfwStatus and the seven mutating ufw actions fail at exec with a command-not-found, which surfaces as execution_failure with no explanation of why.

ufw installed but idle. Worse, and this repo has already been burned by this exact shape. The NON_CANONICAL_ON_DEBIAN doc comment (crates/sysknife-core/src/action_family.rs:98) records it:

an Ubuntu host running firewalld lost firewall management entirely, and UfwStatus answered Status: inactive — a confident wrong answer instead of a refusal.

Substitute nftables for firewalld and Debian for Ubuntu and it is the same bug. An operator asking "is the firewall on" gets "inactive" from ufw while nftables is filtering traffic.

Scope

Two independent pieces; either is a reasonable PR.

1. Read-only truth first. A GetNftablesRuleset action over sudo nft list ruleset, and a state read that reports which backend is in force rather than which frontend was queried. This is the piece that stops the confident wrong answer, and it is Low risk with no approval receipt, so it is the smaller start.

2. Mutating parity, if wanted. nftables equivalents of allow, deny, limit and delete. This is a design question rather than a transcription: ufw's rule model is a thin abstraction and nft's is tables, chains and handles, so UfwDeleteRule's index has no direct analogue. Worth discussing here before code. #234 closed on 10 September and query_ufw_rules now produces the number UfwDeleteRule needs, so the missing-index problem is a ufw one no longer; nft handles are a separate design question.

Either piece needs its packaging/sysknife-sudoers grant, and nft argv is token-matched there like every other tool.

Tests first

Assert the argv, then assert the backend-detection logic against fixtures for three states: nftables active with rules, ufw active, and neither. The third case is the one that must not answer confidently.

Worth deciding alongside

If a host runs nftables, should the ufw actions be refused there rather than offered? That is the NON_CANONICAL_ON_DEBIAN question again, one layer down. #237 closed on 9 September and the family fence now means what it says, so this is a fresh decision rather than part of that surgery.

Difficulty

medium for the read-only action and backend detection. hard for mutating parity, because the rule model differs rather than the syntax.

Getting started

CONTRIBUTING.md has the build and test commands. No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

@QinXi-ai reserved for you as a follow-up to your recent work; the why is on your PR thread. No pressure and no deadline. Reply here and it is formally yours.

[vladimirrott]

@QinXi-ai releasing this one with #238, which it pairs with.

Nothing to do with fit. You have three open PRs here and I had reserved three issues on top of them, which is two more than this project's own rule allows for good reasons. Say the word after your current PRs land and both are yours again.

[vladimirrott]

@mikevillari offering this one to you, on the strength of #398 and #399.

Debian's default firewall is nftables and the catalogue has no nftables vocabulary. I checked before offering:

$ grep -rci nftables crates/sysknife-core/src/action_family.rs crates/sysknife-types/src/lib.rs
crates/sysknife-core/src/action_family.rs:0
crates/sysknife-types/src/lib.rs:0

Why you: adding an action family means placing it correctly in the fence lists, the risk table, the prompt's params reference and the parameter validator. Get one of those wrong and you get a silent hole rather than a red test, which is the failure class both of your PRs are about.

One sequencing note. PR #384 is re-partitioning the fence lists right now and will land first, so start after it does or expect to rebase onto a different set of constant names.

Say the word and I will label and assign it to you. Say no just as freely; it is a step sideways from CI plumbing and there is no expectation attached.

[mikevillari]

Thank you for the offer — I will take this, together with #238. Please mark/assign it to me. I will start after #384 lands as you requested, beginning with the read-only piece: GetNftablesRuleset, accurate backend-state reporting, and regressions for nftables active, ufw active, and neither. I will check the typed action, risk/policy entry, argv validation, planner reference, and sudoers grant together. Mutating firewall parity will stay outside this first PR and needs a separate design discussion. Codex will assist with implementation and validation, with only actually-run checks reported.

[mikevillari]

Releasing my claim on this issue along with #238 because my availability has changed. No implementation has started, so please leave it available for another contributor. Thank you again for offering it and explaining the prerequisite work.

[vladimirrott]

@mikevillari releasing this one alongside #238, as you asked. No implementation started and nothing lost, and the pair goes back in the pool.

[QinXi-ai]

I'll take the released read-only part of this issue alongside #238: GetNftablesRuleset, the exact sudoers grant, and backend-state reporting with fixtures for nftables rules, active ufw, neither, and unavailable/permission-denied probes. An inactive frontend must not be reported as proof that the host has no firewall.

Please assign this to me. Mutating nftables parity is outside this first change and still needs the separate rule-model discussion described above. Codex is assisting with implementation and validation.

[vladimirrott]

@QinXi-ai the read-only half is yours, labelled and assigned. You asked for that
on 10 September and I left it sitting, so the label said nothing and your
dashboard said nothing. My miss.

The scope you named is the scope I want. A reporter that answers unknown on
empty or failed evidence is the entire reason this issue exists, and it is the
half that a fixture suite can actually pin. Mutating parity stays out until the
rule-model discussion happens.

I corrected the body while I was here. #234, #237 and #238 have all closed since
it was filed, and the opening paragraph still described Debian eligibility as
something that might happen. It happened on the 10th. Nothing about the defect
moved:

$ git rev-parse --short=8 HEAD
61b3a878
$ grep -c Ufw crates/sysknife-types/src/lib.rs
8
$ grep -ci nft crates/sysknife-types/src/lib.rs
0