I can start the suricata daemon fine, but trying to run suricata-update as root, I get this error:
27/7/2023 -- 14:55:04 - <Error> -- [ERRCODE: SC_ERR_FOPEN(44)] - Error opening file: "/tmp/tmpuCA4qJ/fast.log": Permission denied
27/7/2023 -- 14:55:04 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - output module "fast": setup failed
27/7/2023 -- 14:55:04 - <Error> -- Suricata test failed, aborting.
27/7/2023 -- 14:55:04 - <Error> -- Restoring previous rules.
running suricata-update as suricata user yields this error:
27/7/2023 -- 14:58:52 - <Error> -- [ERRCODE: SC_ERR_FATAL(171)] - capng_change_id for main thread failed
27/7/2023 -- 14:58:52 - <Error> -- Suricata test failed, aborting.
27/7/2023 -- 14:58:52 - <Error> -- Restoring previous rules.
Both root and suricata users definitely have permissions to read and write to /tmp, so not sure why there’s a permissions issue…I also didn’t see a “run-as” section in update.yaml like in suricata.yaml, so I’m assuming it just executes under the context of the user that invoked suricata-update. I have suricata.yaml configured to run-as suricata group/user.
The error is generated by Suricata, I think. Suricata-Update invokes Suricata to test the config+rules using
-T. So the
suricata.yaml is relevant here. Still, I’m not sure why it gives this error.
My main concern is with that last error stating that the old rules were restored. To me, that means no rules have been updated and the rules I have disabled in disabled.conf are still enabled. Is that the case?
Please post your suricata.yaml for further debugging, also the version of Suricata and suricata-update
This appears to happen when the
run-as section of
suricata.yaml is configured. When
suricata-update is run, it first creates a temporary directory, but does not set the permissions to respect
run-as, and while it should try, this may still fail. So more investigation is required here.
My personal preference is to do what the RPM packages do:
- do not specify a
run-as section in
- use the command line arguments for setting the user and group (in the systemd unit file)
I think this provides a good balance of expected usage from the command line and systemd. But I’ll create a ticket to see if we can do better: Bug #6241: Suricata test-mode can fail when user and group provided with run-as. - Suricata-Update - Open Information Security Foundation
Sure enough, commenting out
suricata.yaml and adding the user/group arguments to the unit file allows
suricata-update to run to completion. Thank you for your help and investigation into this bug @ish !