Re: security/clamav: /ar/run on TMPFS renders the port broken by design

On Sun, 28 Aug 2022 11:37:16 +0200
Michael Gmelin <grembo@freebsd.org> wrote:

> > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > 
> > Cy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):  
> >> As stated before in this thread, replacing /var/run with tmpfs is
> >> not a supported configuration.  
> > 
> > Not supported? What is the purpose of /etc/rc.d/var then? That
> > creates a tmpfs backed /var, populates it through mtree, and makes
> > a proper /var/run available.
> > 
> > However it doesn't (yet) create /var/run/clamav of course.
> > 
> > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > walks through /usr/local/etc/mtree/* and runs mtree on each of the
> > files found as needed. All that the security/clamav port would need
> > to do then is to drop an appropriate small mtree file as
> > /usr/local/etc/mtree/clamav. From a port's perspective that is the
> > same logic as dropping service scripts as
> > /usr/local/etc/rc.d/clamav-*.  
> 
> From a user's perspective, it would be preferable to have this happen
> at service start though, as (unlike in the setup described) reboots
> don't happen that frequently, but files in /var/run might get deleted
> manually. Maybe some rc framework based solution would make sense,
> e.g., a variable `mtree_files`, which, if set, is applied in the
> default start_precmd. Besides being more resilient, this would also
> have the advantage that all required file systems should be available
> at that point and the separation between system and ports would be
> more clear. Another advantage would be that directories are only
> created for services that are actually enabled/started.

Yes, something in the RC framework would be nice.