From nobody Mon Aug 29 09:12:44 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MGPqQ2FtQz4Zggr; Mon, 29 Aug 2022 09:13:06 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MGPqM756mz3nRB; Mon, 29 Aug 2022 09:13:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 27T9Cimb002833; Mon, 29 Aug 2022 18:12:44 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 29 Aug 2022 18:12:44 +0900 From: Tomoaki AOKI To: Franco Fichtner Cc: FreeBSD User , Cy Schubert , Michael Gmelin , freebsd@oldach.net, otis@freebsd.org, Current FreeBSD , FreeBSD Ports , yasu@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> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MGPqM756mz3nRB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-pkg@FreeBSD.org,freebsd-ports@freebsd.org,freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_SEVEN(0.00)[10]; R_DKIM_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 29 Aug 2022 10:31:28 +0200 Franco Fichtner wrote: > Hi, > > > On 29. Aug 2022, at 8:24 AM, FreeBSD User 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