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

On Sun, 28 Aug 2022 03:21:24 -0700
Cy Schubert <Cy.Schubert@cschubert.com> wrote:

> In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>,
> Michael Gmelin w
> rites:
> > 
> >
> >  
> > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > >=20
> > > =EF=BB=BFCy 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.  
> > >=20
> > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > creates a t=  
> > mpfs backed /var, populates it through mtree, and makes a proper
> > /var/run av= ailable.  
> > >=20
> > > However it doesn't (yet) create /var/run/clamav of course.
> > >=20
> > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > walks thro=  
> > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > found as need= ed. All that the security/clamav port would need to
> > do then is to drop an ap= propriate small mtree file as
> > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > the same logic as dropping service scripts as /usr/local/=
> > etc/rc.d/clamav-*.
> >
> > =46rom a user's perspective, it would be preferable to have this
> > happen at s= ervice start though, as (unlike in the setup
> > described) reboots don't happen= that frequently, but files in
> > /var/run might get deleted manually. Maybe so= me rc framework
> > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > which, if set, is applied in the default start_precmd. Besides
> > being mo= re resilient, this would also have the advantage that all
> > required file syst= ems should be available at that point and the
> > separation between system and p = orts would be more clear. Another
> > advantage would be that directories are on= ly created for services
> > that are actually enabled/started.  
> 
> Unfortunately this requires all ports to include an mtree file.
> Relying on port maintainers who are human to ensure that these files
> are created and updated when ports are created and maintained will
> result in more human error. I've learned over my long career to rely
> more on automation than human beings. Automation [should] never fail
> and when it does it does temporarily until the bug is found and
> fixed. Human beings inconsistently fail.
> 
> If it were an auto-discovery script that created an mtree file as
> part of the packaging process, it would be another matter. But this
> optional solution path should be discussed on ports@, not here.
> 
> 

I don't have much skin in the game, but I created a little proof of
concept to allow further discussion (which is not ports-specific, as it
works for all service scripts):

https://reviews.freebsd.org/D36385

This basically allows both system admins and port maintainers to
create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
always relative to the service script called) which are automatically
applied on service start. It's non-intrusive and doesn't require any
sweeping changes to existing ports/services.

In this specific case, the requester could create
/usr/local/etc/mtree/clamav-clamd with the required content (or
persuade the port maintainer to include that file).

You could of course add some construct to the ports framework that
picks up certain directories from the package list automatically and
places them into an mtree file as part of the build or installation
process. But that would be an additional feature on top of this change.

This is meant to inspire more discussions, I'm not trying to force
anything in. ;)

Cheers
Michael

-- 
Michael Gmelin