From nobody Mon Aug 29 08:31:28 2022 X-Original-To: freebsd-current@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 4MGNvc0Sxpz4bbRf; Mon, 29 Aug 2022 08:31:40 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d3::107:1]) (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 4MGNvb1DMhz3hGB; Mon, 29 Aug 2022 08:31:38 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from smtpclient.apple (p200300cd873ac5fc3984e35a6110a933.dip0.t-ipconnect.de [IPv6:2003:cd:873a:c5fc:3984:e35a:6110:a933]) by host64.shmhost.net (Postfix) with ESMTPSA id 4MGNvP3m8LzP2Hd; Mon, 29 Aug 2022 10:31:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by design From: Franco Fichtner In-Reply-To: <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de> Date: Mon, 29 Aug 2022 10:31:28 +0200 Cc: Cy Schubert , Michael Gmelin , freebsd@oldach.net, otis@freebsd.org, Current FreeBSD , FreeBSD Ports , yasu@freebsd.org, "freebsd-pkg@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: FreeBSD User X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Virus-Scanned: clamav-milter 0.103.6 at host64.shmhost.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4MGNvb1DMhz3hGB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of franco@lastsummer.de has no SPF policy when checking 2a01:4f8:a0:51d3::107:1) smtp.mailfrom=franco@lastsummer.de X-Spamd-Result: default: False [-1.60 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkg@FreeBSD.org,freebsd-ports@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_SEVEN(0.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[lastsummer.de]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > On 29. Aug 2022, at 8:24 AM, FreeBSD User = wrote: >=20 > 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=