Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Aug 2022 03:21:24 -0700
From:      Cy Schubert <Cy.Schubert@cschubert.com>
To:        Michael Gmelin <grembo@freebsd.org>
Cc:        freebsd@oldach.net, Cy.Schubert@cschubert.com, otis@freebsd.org, freebsd@walstatt-de.de, freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org
Subject:   Re: security/clamav: /ar/run on TMPFS renders the port broken by  design
Message-ID:  <20220828102124.409EC26D@slippy.cwsent.com>
In-Reply-To: <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
References:  <202208280842.27S8gDXn055868@nuc.oldach.net>  <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220828102124.409EC26D>