Suricata-update aborts with permission error

Help
1

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.

2

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.

3

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?

4

Please post your suricata.yaml for further debugging, also the version of Suricata and suricata-update

5

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 suricata.yaml
  • 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

2 Likes
6

Sure enough, commenting out run-as in 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 !