Clean up /var/cache /var/tmp /tmp use

[connortechnology]

The /tmp/zm/ directory is somewhat redundant in light of /var/cache/zoneminder/temp/, and the latter presents none of the security risks of the former. Why not have all the temp stuff live in one location under /var?

This comes from debian bug tracker as a wish list item.

On thinking about it, we really should verify that nothing sensitive goes to /tmp. At present for exporting and archiving downloads, etc, we write to /var/tmp. systemd somewhat mitigates this by sandboxing, but we should just do it right in the first place.

We should also (in debian packaging) be writing our events by default under /var/lib/zoneminder to sync up with redhat.

[onlyjob]

That's from the https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858682

If I remember correctly, tmpfs-mounted /tmp could provide with advantages of being faster than long term storage /var/cache/zoneminder/temp/ which might be NFS-mounted.

Perhaps /tmp could be protected with systemd's PrivateTmp=true?

[connortechnology]

There are definite performance advantages, which is why many of our tmp files have gone into /tmp or /run. However a lot of them can be large video files which can fill up a tmpfs pretty quick, so we have been using /var/tmp.

Systemd has been helping a lot with the security aspect. I don't know if PrivateTmp=True is the default but in my ubuntu systems, the apache process is PrivateTmp=true and that helps a lot when exporting video.

There is a setting that used to default to on for zms, where it would cache video frames to disk to act as a rewind buffer. This worked ok when saving to /tmp but when we moved it to /var/tmp performance suffered greatly. I have since set the default to off for this feature. In future I think we should just keep the jpegs in ram. I don't see any advantage to writing them out to disk.

[onlyjob]

PrivateTmp=True is unlikely to be a system default but it is easy to set it up per .service file when required. I think I've used /tmp to buffer event's jpegs because otherwise checking event was too slow...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[petterreinholdtsen]

The Debian bug report is still unresolved.