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

Hi,

> On 29. Aug 2022, at 8:24 AM, FreeBSD User <freebsd@walstatt-de.de> wrote:
> 
> Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var reside on a memory
> disk and the way NanoBSD handles /var, contradicts some claims that is is 'unsupported' to put
> /var on a volatile memory infrastructure.

I fully agree with the situation that at least NanoBSD has always been a valid
use case for this and don't see the need to "recycle" contents in /var/run and
let alone assume software that state inside /var/run is not volatile.

Milage varies for other /var related subdirectories of course, but people using
a /var MFS type setup have managed the situation for many years anyway with all
of its ups and downs.

The situation is a bit sloppy on the ClamAV end and has been for a couple of
releases assuming this and that and failing on tmpfs nodes, not bootstrapping
required things in the first place, but let's just assume that is the case for
other software as well now or in the future.

> what (fatal?) implications does it have to create some folders by port's rc-script in /var/run
> or whatever folder is needed to be on a volatile memory device for FreeBSD base system's mtree
> infrastructure?

So the obvious "separation of concerns" solution isn't something that was being
discussed here seeing that this is a ports/packages related issue:

The fix in all cases is to upgrade/reinstall the package in question, so
the knowledge of these required directories is buried inside the +POST_INSTALL
script but you cannot easily re-run these scripts since there is no command
option for it.  Obviously this beats having a copy of the package lying around
just to reinstall it on a reboot...

In the past you were able to extract them from "pkg info --raw $packagename",
and run them in the shell but that workaround is no longer feasible for LUA
scripting was added since pkg uses internal definitions in the ports tree
provided scripts.

Whether or not someone will have to script something to rerun the +POST_INSTALL
on reboot shouldn't stop from adding a pkg script run option to enable the former.

Solutions not involving the actual ports scripts seem to be over-engineering
when trying to record "unknown state" for a "reproducible outcome".  ;)


Cheers,
Franco