clamd log contains "ERROR: Can't unlink the pid file /var/run/clamd.pid" on each restart

[hannob]

Describe the bug

I noticed each restart of clamd causes an error in the log file:

ERROR: Can't unlink the pid file /var/run/clamd.pid

The problem seems rather obvious. clamd generates the pid file with the root user, however it then drops privileges to the clamav user, thus being unable to delete the pid file owned by root.

There are avarious possible ways to fix this, e.g.:

• Generate the pid after dropping privileges in a dir where the clamav user has write permission (this would break some existing setups that use the pid file in any scripts etc.)
• chown the file after generation to the clamav user

Though I'd like to point out I'm not very familiar with unix server programming. But the way it works right now is obviously not working.

How to reproduce the problem

Start and stop clamd, check the log for "ERROR".

[val-ms]

In one of the previous releases (I forget which) we changed the behavior to make sure the pid-file is owned by root when clamd is started by root. This was to resolve a very small security risk. Bug: https://bugzilla.clamav.net/show_bug.cgi?id=12435 Fix: https://github.com/Cisco-Talos/clamav/commit/5b168b50cdd0c0650eca3047097a3f6919e8ab64

I guess some less-intelligent service management tools that rely on the pid-file when they need to kill the process and a nefarious user may trick the service manager into killing the wrong process by changing the pid-file.

The change log notes "This change does make the services unable to clean up the PID file on exit." I don't know if there is a solution to this outside of maybe removing the logic to delete the pidfile automatically.

@ragusaa is the most familiar with this code and may have a better answer.

Note: There's also a related fix touching this code to consider if we make more changes: Bug: https://bugzilla.clamav.net/show_bug.cgi?id=12597 Fix: https://github.com/Cisco-Talos/clamav/commit/ec62e185080f1b1a794ef554fb91fe9d05c098f6

[hannob]

Reading the bugzilla discussion I then believe there's no ideal solution and the best course of action would probably be to just leave the stray pid file and not emit an error to the log.