Repository navigation
Conversation
opensnitch.service's system-bridge drop-in used Requires= on snitchwatch-system-bridge-grpc.socket, so stopping the socket also stopped the firewall daemon and it stayed down after the socket came back (r8 VM: 0 NFQUEUE rules, a deny-default connection passed). Use Wants= with the same After= ordering instead: boot still pulls the socket in first, but losing it leaves the daemon running on its default action. The build verifier, the readiness helper, the boot check and the tests now expect Wants=.
The readiness helper and boot check now also refuse the socket in opensnitch.service's Requires=, Requisite=, BindsTo= or PartOf=, so a change to the main unit can't reintroduce the stop propagation the Wants= drop-in removed. Record the owner's confirmation that the two-action notification allowlist is policy.
This was referenced Oct 8, 2026
Owner
Author
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.
Stacked on #85. This keeps the firewall up when the system bridge's gRPC socket is stopped. The owner made the decision on 2026-10-08.
Problem
opensnitch.service's system-bridge drop-in hadRequires=snitchwatch-system-bridge-grpc.socket. On the r8 VM,systemctl stopof that socket also stoppedopensnitchd, and it stayed down after the socket came back. Nothing was being enforced: there were 0 NFQUEUE rules and a deny-by-default connection passed. Only root can trigger this, and it has been there since #76.Change
Wants=with the sameAfter=. At boot the socket is still pulled in and ordered before the daemon. Stopping it no longer stops the daemon, which falls back to its default action while no UI is connected (stock OpenSnitch behaviour without a GUI).Wants=.Requires=,Requisite=,BindsTo=orPartOf=, so an edit to the main unit can't bring the stop back. A new test covers each of the four, and it fails if the check is removed.CHANGE_RULE/DELETE_RULE) is policy.Test plan
tests/test-snitchwatch-system.py(61),tests/test-snitchwatch-system.sh,tests/test-snitchwatch-image-build.py,tests/test-snitchwatch-image-build-daemon.pypasstests/boot-check.sh;just checkR10-VM-ACCEPTANCE-RESULT.json):opensnitchdstays active, its NFQUEUE rules stay, and it reconnects to the bridge without a restart;systemctl show --alllists the empty dependency properties)