Date: Mon, 29 Aug 2022 18:12:44 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Franco Fichtner <franco@lastsummer.de> Cc: FreeBSD User <freebsd@walstatt-de.de>, Cy Schubert <Cy.Schubert@cschubert.com>, Michael Gmelin <grembo@freebsd.org>, freebsd@oldach.net, otis@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, yasu@freebsd.org, "freebsd-pkg@freebsd.org" <freebsd-pkg@FreeBSD.org> Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by design Message-ID: <20220829181244.f0354f2433e668f467ff6391@dec.sakura.ne.jp> In-Reply-To: <25A758F5-784E-45EC-8F9A-278E0D3AB8DE@lastsummer.de> References: <202208280842.27S8gDXn055868@nuc.oldach.net> <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> <20220828102124.409EC26D@slippy.cwsent.com> <20220828130107.1a76d54a.grembo@freebsd.org> <20220828131120.C3781317@slippy.cwsent.com> <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de> <25A758F5-784E-45EC-8F9A-278E0D3AB8DE@lastsummer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Aug 2022 10:31:28 +0200
Franco Fichtner <franco@lastsummer.de> wrote:
> 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.
Uncertain about current default, but at least, at some point,
varmfs="AUTO" on /etc/defaults/rc.conf forcibly create and mount
mfs on /var, overriding existing contents, unless varmfs="NO"
exists on /etc/rc.conf[.local].
If the behaviour is unchanged until now, no port SHALL assume
non-volatile /var, and use usually-non-volatile {LOCALBASE}/var instead.
At least, security/rkhunter uses there.
For use-case writes to non-volatile fs is prohibited and volatile
fs'es are mandated to be cleared daily, the admin should create
script(s) to
1. stop all jobs writing to (allowed) volatile fs,
2. clear volatile fs'es,
3. then restart stopped jobs
on {LOCALBASE}/etc/periodic/daily.
> > 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
>
--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220829181244.f0354f2433e668f467ff6391>