Bug #2058
closedSuricata unable to remove PID file when privileges are dropped
Description
The PID file is written out before privileges are dropped which makes Suricata unable to remove it at exit as the file is owned by root.
I'm not sure what the best approach is to fix it. Either:
- Delay writing of the pid file to PreRunPostPrivsDropInit, but still do the pid file check in the current place.
- Or keep pid file creating in its current stop and chown it to the user/group that Suricata is requested to run as.
Updated by Victor Julien about 7 years ago
Either way could work I guess. Any idea how other tools do this?
Updated by Jason Ish about 7 years ago
There is information out there that perhaps the current method is best:
That is, Suricata will clean it up if it can, otherwise not worry about. Systemd can solve this pretty easily with a pre-run, or post-stop hook that does the additional cleanup. Other init systems could adapt as needed.
A third option, is to drop the PID after dropping privileges, but right it to a "suricata" user owned directory, ie: /var/run/suricata/, where the "suricata" owned socket file is written.
Updated by Jason Ish about 7 years ago
- Status changed from Assigned to Rejected
Leaving pid file handling as is. It seems to be the most accepted way to do it when dropping privileges. Systemd is fully capable of cleaning it up, so leave it to startup scripts, etc.