Hello Suricata Development Team,
I’ve been deploying and maintaining Suricata on Windows environments, and I wanted to log an issue regarding cross-platform compatibility with suricata-update.
While suricata-update is an exceptional utility for Linux and POSIX-compliant systems, running it natively on Windows consistently triggers file-locking exceptions (specifically [Errno 13] Permission denied during temporary file operations and archive extraction/moving phases).
The Root Cause
Unlike Unix-based operating systems—which allow files and directories to be moved or deleted while an open handle exists—Windows NT enforces strict exclusive file and directory locking. When Python’s tempfile module or internal file-copy routines in suricata-update attempt to manipulate the downloaded tarball or extraction directories before handles are fully released, Windows blocks the operation outright.
Impact on Windows Users
Because of this behavior, Windows administrators are forced to build custom native PowerShell wrappers (using utilities like tar.exe to bypass Python file locking entirely) just to automate baseline rule updates.
Suggested Improvements / Feature Request
-
Windows-Native Handle Management: Implement explicit handle closing and robust exception handling (or retry loops with backoff) around temporary directory operations for Windows environments.
-
Alternative Extraction Path: Provide a fallback mechanism on Windows that utilizes native OS utilities (
tar.exeorExpand-Archive) rather than relying purely on Python’s strict file-system wrappers. -
Official Windows Guidance: Expand documentation regarding Windows file-locking quirks or officially acknowledge the limitation so users aren’t left troubleshooting upstream Python exceptions.
Thank you for your continued work on Suricata and for making such a powerful IDS accessible across platforms. Any improvements to native Windows rule management would be immensely appreciated by the community!
Best regards,
Michael Steele