Closed stusmall closed 8 months ago
Hi @stusmall ,
Yes, you're correct. This has been tagged as FIXME for some years now, and since we're introducing some unstable changes maybe it's time to rewrite it.
@gustavo-iniguez-goya is there any known risk in continuing to declare rules in this way? Do you know of any impact it will have besides crashing the rule builder UI?
Also is there an existing issue I can point to and close this as a dupe? Or should I leave this issue open?
The daemon loads the rule from disk, and it only parses the List field, it ignores the "data" field of the operator. So it should work just fine. But take a look at the logs, if there's any problem loading or saving the rules there should be an ERR log.
Let's keep this issue open. There was a request to always expand the json encoded data in the List json field, but I haven't found the issue number.
hey @stusmall , I've changed the behaviour to no longer convert operator list to a JSON string. The conversion is still needed on the GUI side, in order to save it to the DB, because the DB is not normalized.
I'd have preferred to defuse a bomb rather than changing this part of the app :)
Could you test that everything keeps working as expected?
Will do! Next chance I can I'll pull down, build and test it. It'll probably be pretty late in the week until I can
Quick description of the bug The heart of the issue is that the UI duplicates data in created list rules and uses the data in two different contexts. This makes managing JSON rules outside the UI either error prone or will crash the UI rule builder.
Detailed description of the bug If a rule is disabled the operators inside of a list will only be included as a serialized JSON string inside data. When the rules is enabled the data will still be included as a serialized JSON string on data but also as a JSON list in the list property. For example see these two rules:
and
where the only difference in the UI is if enabled is selected.
From experimentation it appears that the UI is using the contents of
data
to populate the rule builder but the daemon uses the contents oflist
to evaluate the rule.The issue for me as a user is because I use NixOS. All opensnitch rules are written in the nix language and then translated into JSON on a system rebuild. This gives me the choice of trying to replicate the UI's behavior when writing rules or to keep it DRY. When replicating the UI's behavior I found it to be error prone trying to keep the list and data fields in sync.
I've been going the route where a list operator leaves data null and only puts the nested rules under list. For example the following nix rule:
produces the following JSON
This rule behaves exactly how I want it to except it will crash the UI if I ever try to edit the rule. The stack trace from this crash is included later. This isn't the end of the world. The program behaves mostly as it should. When managing rules with nix I usually don't want to also manage it in the UI. It's just the UI is helpful for troubleshooting or finetuning rules.
System Info
Linux nixos 6.5.5 #1-NixOS SMP PREEMPT_DYNAMIC Sat Sep 23 09:14:39 UTC 2023 x86_64 GNU/Linux
To Reproduce Steps to reproduce the behavior:
Post error logs:
Additional context I just wanted to save massive thank you for this project! It's extremely well made and useful!