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

In message <20220827082638.57901a72@slippy>, Cy Schubert writes:
> On Sat, 27 Aug 2022 15:38:44 +0200
> Juraj Lutter <otis@FreeBSD.org> wrote:
>
> > > On 27 Aug 2022, at 15:27, Michael Gmelin <grembo@freebsd.org> wrote:
> > >=20
> > >=20
> > >  =20
> > >> On 27. Aug 2022, at 15:18, freebsd@oldach.net wrote:
> > >>=20
> > >> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST=
> ): =20
> > >>> (you're removing /var/run, which shouldn't be removed =20
> > >>=20
> > >> Not quite. It's actually not uncommon to boot with an empty /var. Plea=
> se see /etc/rc.d/var and related. =20
> > >=20
> > > That=E2=80=99s a good point.
> > >  =20
> > >> The request that ports/packages should consider this case is not exact=
> ly unreasonable IMO.
> > >>  =20
> > >=20
> > > If I was the maintainer, I would simply add the code to create the dire=
> ctory for robustness sake (I for one deleted subdirs in /var/run more than =
> once and would expect a port to fix this on restart, also to make sure corr=
> ect permissions are applied). But since it doesn=E2=80=99t seem like this i=
> s going to happen, adding a custom rc file would be a viable short term wor=
> karound for the requester.
> > >=20
> > > I like the idea of having something like tmpfiles.d, it would also help=
>  port maintainers (could also be done as a port).
> > >  =20
> >=20
> > As I have stated in one of those PR: clamd creates file in two locations:
> >=20
> > - PidFile
> > - LocalSocket
> >=20
> > Both the locations could be checked by rc.d script in clamd.conf (also fr=
> eshclam eventually) and respective directories can be created from within s=
> tart_precmd()
> >=20
> > otis
> >=20
> > =E2=80=94
> > Juraj Lutter
> > otis@FreeBSD.org
> >=20
>
> As stated before in this thread, replacing /var/run with tmpfs is not a
> supported configuration. However if users wish to replace /var/run
> with tmpfs they can create an rc script (I put my extra rc scripts in
> /etc/local/rc.d) to create the hierarc
> If one does this they can either use mtree(1) to create the hierarchy
> or simply take a snapshot (find /var/run -type d | cpio -o >
> /etc/local/my_var_run.cpio), having their rc script recreate the
> hierarchy using cpio -i < /etc/local/my_var_run.cpio). And
> be periodically updated the archive as needed, probably through a
> shutdown script.
>
> One will notice that /etc/mtree/BSD.var.dist shows us what is created
> in /var/run by default during installworld.
>
> The change requested is not specifically for an individual port but
> essentially a FreeBSD-wide infrastructure change. I don't think this
> is reasonable without a lot of consideration about what will be broken
> during the process of changing build and boot processes and the
> potential POLA fallout from such a change. A change like this needs to
> be architected.
>
> I don't think this is the mailing list to discuss this topic. This
> should be discussed on ports@. Not here. Maybe it should be moved there
> as this is a ports not a base O/S issue.

This will resolve the problem:

#!/bin/sh

# PROVIDE: kq-var-run
# REQUIRE: zfs tmp
# BEFORE: FILESYSTEMS

. /etc/rc.subr

name=kq_var_run
rcvar=kq_var_run_enable
extra_commands="update create"
start_cmd="kq_var_run_start"
create_cmd="kq_var_run_create"
update_cmd="kq_var_run_create"
# stop_cmd="kq_var_run_create"

load_rc_config $name

# Set defaults
: ${kq_var_run_enable:="NO"}
: ${kq_var_run_mtree:="/etc/local/mtree/KQ.var-run.mtree"}

kq_var_run_start() {
	df -ttmpfs /var/run > /dev/null 2>&1 &&
		mtree -f ${kq_var_run_mtree} -p /var/run
}

kq_var_run_create() {
	mtree -cbdj -p /var/run > ${kq_var_run_mtree}
}

run_rc_command "$1"

A person could add stop_cmd="kq_var_run_create" to save the /var/run mtree 
at shutdown instead of manually. Works with tmpfs /var/run.


-- 
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