Added by Shivani Bhardwaj about 6 years ago. Updated about 2 years ago.
Description
If a directory is not owned or managed by suricata-update, it throws an error. This happens because following the usual procedure in order to see if there has been any change in the rule files in a given directory, it tries to hash all the contents of the directory and match against that.
./bin/suricata-update -o /tmp
Attached
Files
| output.txt (16.4 KB) output.txt | Shivani Bhardwaj, 11/20/2018 04:01 PM |
This isn't something we see coming up in generate usage of Suricata-Update so I'm not sure about the priority. Plus, needing to move in files for datasets, and md5's (https://redmine.openinfosecfoundation.org/issues/2688) are going to complicate things.
I wonder if the answer is to drop a cookie. When running, if the output directory does not exist, create it, and drop a cookie file (.suricata-update). If its empty, drop the cookie file. Otherwise check if the cookie exists, and refuse to run if not with a meaningful error message.
I wonder if the answer is to drop a cookie. When running, if the output directory does not exist, create it, and drop a cookie file (.suricata-update). If its empty, drop the cookie file. Otherwise check if the cookie exists, and refuse to run if not with a meaningful error message.
This makes sense. Should this work be carried on or dropped or halted till #2688 is addressed?
Shivani Bhardwaj wrote:
I wonder if the answer is to drop a cookie. When running, if the output directory does not exist, create it, and drop a cookie file (.suricata-update). If its empty, drop the cookie file. Otherwise check if the cookie exists, and refuse to run if not with a meaningful error message.
This makes sense. Should this work be carried on or dropped or halted till #2688 is addressed?
Lets hold off until #2688 is addressed.