Bug #2691
openError thrown with -o option
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.
Steps to reproduce¶
./bin/suricata-update -o /tmp
Actual output¶
Attached
Files
Updated by Shivani Bhardwaj over 5 years ago
- Status changed from New to Assigned
- Assignee changed from Jason Ish to Shivani Bhardwaj
- Target version set to TBD
Updated by Shivani Bhardwaj over 5 years ago
- Status changed from Assigned to Feedback
Updated by Jason Ish about 5 years ago
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.
Updated by Shivani Bhardwaj almost 5 years ago
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?
Updated by Jason Ish almost 5 years ago
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.
Updated by Jason Ish almost 5 years ago
- Blocked by Bug #2688: filemd5 files are not migrated /w rules added
Updated by Shivani Bhardwaj over 4 years ago
- Status changed from Feedback to Assigned