Hi. With the default run-as suricata uid:gid, the suricata-update command fails to run. Reproducible: Always Actual Results: ... 9/3/2023 -- 21:09:57 - <Info> -- Writing /var/lib/suricata/rules/classification.config 9/3/2023 -- 21:09:57 - <Info> -- Testing with suricata -T. 9/3/2023 -- 21:09:57 - <Error> -- [ERRCODE: SC_ERR_FOPEN(44)] - Error opening file: "/tmp/tmpkbec7arg/fast.log": Permission denied 9/3/2023 -- 21:09:57 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - output module "fast": setup failed 9/3/2023 -- 21:09:57 - <Error> -- Suricata test failed, aborting. 9/3/2023 -- 21:09:57 - <Error> -- Restoring previous rules. Expected Results: ... 9/3/2023 -- 21:13:32 - <Info> -- Writing /var/lib/suricata/rules/classification.config 9/3/2023 -- 21:13:32 - <Info> -- No changes detected, exiting. Workaround is to comment these lines in /etc/suricata/suricata.yaml to force running as root #run-as: # user: suricata # group: suricata
Created attachment 857087 [details] full log of surricata-update failure
Another temporary tweak is to adjust the group permissions on classification.config and suricata.rules chmod g+w /var/lib/suricata/rules/* However, the permissions revert after running the update again. So.. not a great workaround unless you run that first every time in a script? # ls -l /var/lib/suricata/rules/ -rw-rw-r-- 1 root suricata 3228 Mar 9 21:28 classification.config -rw-r--r-- 1 root suricata 24291189 Mar 9 21:28 suricata.rules Hope this helps
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8532e51714ce99ea6db20cfedde4d976291e70d3 commit 8532e51714ce99ea6db20cfedde4d976291e70d3 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2023-03-22 23:02:00 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2023-03-22 23:43:34 +0000 net-analyzer/suricata: make rule-file and update dirs setuid suricata So that it is possible to run suricata-update as root (which according to upstream documentation is still very much allowed) but have suricata itself drop its privileges, without having to manually change the ownership of downloaded files. In the long run it would be nice for suricata-update to drop privileges as well - but that's something for upstream to take care of, and setuid suricata on the relevant directories appears to work fine. Closes: https://bugs.gentoo.org/900627 Signed-off-by: Marek Szuba <marecki@gentoo.org> net-analyzer/suricata/suricata-6.0.10.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
