The preferred location for the system daemon PID file is executed as a non-root user.

My question is related to this question , but the processes in question are executed from cron and from non-root users. Thus, many users do not have home disks (or their home directories point to /usr/share/package_name , which is not the ideal location for the PID file).

Saving to /var/run problematic because this directory is not writable except by root.

I could use /tmp , but I wonder if this is ideal for security reasons.

I could arrange for a script to run to create a directory in /var/run that belongs to the corresponding user (I cannot do this when the package is installed, since /var often mounted as tmpfs, therefore it is not permanent).

What is the best practice here?

+7
source share
2 answers

Good question :), now I have exactly the same. I am not sure if this is the correct answer, but I hope this helps, and I am also grateful for the feedback.

I searched googled and found that registering each daemon user as a dbus service is an elegant solution. dbus can verify that the service only works once. no need for pidfile.

Another solution (my current) would be to create a PID file in a directory, for example:

 $HOME/.yourdaemon/pid 

After your comment, I realized that you cannot write at home. I would suggest studying dbus

Update

I have an idea. What if you use / tmp but look for a pidfile called yourdaemon.pid.UNIQUE_KEY and belongs to the daemon user? This should work fine.

UNIQUE_KEY must be randomly generated (it is preferable to use tempnam, since it is a proof of race conditions).

+2
source

@Flimzy - What is a security issue?

Of course, if someone has access to the machine, can they use the ps system command? Then they get the process identifier from the mouth of the horses.

So the answer is to put it where you want and focus on other security issues. That is how this person gets access to your car?

-2
source

All Articles