From nobody Mon Aug 29 06:24:47 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 4MGL5z3Hpzz4bPb1; Mon, 29 Aug 2022 06:25:27 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4MGL5x4l2bz3XR9; Mon, 29 Aug 2022 06:25:25 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id EDFD910A1E8B; Mon, 29 Aug 2022 08:25:17 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id E15BA10A1E98; Mon, 29 Aug 2022 08:25:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1661754315; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dYhJL1zs8hPl53/PvgZQ9OP1VkmLXaKRiuRdxz4ZT+s=; b=XMLc5MoPkayMHP8YEfPpU5gcWr6KeII/AmKzO8FMEmwQE6DePVgp9KTWPa7UXU3FT7q+CV V9bIyTvTgHT6Zejg6itUzIbggY9baCuYuiGGABYAkbiiLHA+F8Ydk/pvEEWNc079D7QiU/ fHeqZthazr6rE+FysZfLcXNtFEpR9/aOV+stTNObDaT/8LHFcrvPA9LZy8GP8sq5xja9nZ UfLcDmUgM1hU9OBI2c2I+Q0ejVVcYO695U/q2kL7sCpPPkCcbczoIUBD+z3yjPiTqw3Eyi n5deDTXxvb9VtocLcJ3dH3gzKztZnzaYQjIsrJ3oYUUVX85BTcARt40HIPoxSA== Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-012-115-185.89.12.pool.telefonica.de [89.12.115.185]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 7B04C10A1EA5; Mon, 29 Aug 2022 08:25:15 +0200 (CEST) Date: Mon, 29 Aug 2022 08:24:47 +0200 From: FreeBSD User To: Cy Schubert Cc: Michael Gmelin , freebsd@oldach.net, otis@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by design Message-ID: <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20220828131120.C3781317@slippy.cwsent.com> 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> Organization: walstatt-de.de 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: faa7e9 X-Rspamd-UID: 0497e6 X-Rspamd-Queue-Id: 4MGL5x4l2bz3XR9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=XMLc5MoP; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am Sun, 28 Aug 2022 06:11:20 -0700 Cy Schubert schrieb: > In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin > writes: > > > > > > > > On Sun, 28 Aug 2022 03:21:24 -0700 > > Cy Schubert wrote: > > > > > In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>, > > > Michael Gmelin w > > > rites: > > > > > > > > > > > > > > > > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote: > > > > >=20 > > > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 > > > > > (CEST): > > > > >> As stated before in this thread, replacing /var/run with tmpfs > > > > >> is not a supported configuration. > > > > >=20 > > > > > Not supported? What is the purpose of /etc/rc.d/var then? That > > > > > creates a t= > > > > mpfs backed /var, populates it through mtree, and makes a proper > > > > /var/run av= ailable. > > > > >=20 > > > > > However it doesn't (yet) create /var/run/clamav of course. > > > > >=20 > > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that > > > > > walks thro= > > > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files > > > > found as need= ed. All that the security/clamav port would need to > > > > do then is to drop an ap= propriate small mtree file as > > > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is > > > > the same logic as dropping service scripts as /usr/local/= > > > > etc/rc.d/clamav-*. > > > > > > > > =46rom a user's perspective, it would be preferable to have this > > > > happen at s= ervice start though, as (unlike in the setup > > > > described) reboots don't happen= that frequently, but files in > > > > /var/run might get deleted manually. Maybe so= me rc framework > > > > based solution would make sense, e.g., a variable `mtree_fil= es`, > > > > which, if set, is applied in the default start_precmd. Besides > > > > being mo= re resilient, this would also have the advantage that all > > > > required file syst= ems should be available at that point and the > > > > separation between system and p = orts would be more clear. Another > > > > advantage would be that directories are on= ly created for services > > > > that are actually enabled/started. > > > > > > Unfortunately this requires all ports to include an mtree file. > > > Relying on port maintainers who are human to ensure that these files > > > are created and updated when ports are created and maintained will > > > result in more human error. I've learned over my long career to rely > > > more on automation than human beings. Automation [should] never fail > > > and when it does it does temporarily until the bug is found and > > > fixed. Human beings inconsistently fail. > > > > > > If it were an auto-discovery script that created an mtree file as > > > part of the packaging process, it would be another matter. But this > > > optional solution path should be discussed on ports@, not here. > > > > > > > > > > I don't have much skin in the game, but I created a little proof of > > concept to allow further discussion (which is not ports-specific, as it > > works for all service scripts): > > > > https://reviews.freebsd.org/D36385 > > I've been toying with the idea for a few months but was never bothered to > create a review or even a script for that matter. > > > > > This basically allows both system admins and port maintainers to > > create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's > > always relative to the service script called) which are automatically > > applied on service start. It's non-intrusive and doesn't require any > > sweeping changes to existing ports/services. > > Understood that this is a manual process. > > > > > In this specific case, the requester could create > > /usr/local/etc/mtree/clamav-clamd with the required content (or > > persuade the port maintainer to include that file). > > > > You could of course add some construct to the ports framework that > > picks up certain directories from the package list automatically and > > places them into an mtree file as part of the build or installation > > process. But that would be an additional feature on top of this change. > > Someone could. Personally, I think that's a lot of work compared to simply > saving the state of /var/run at shutdown and restoring it at boot. I can't > speak for the ports management though. > > > > > This is meant to inspire more discussions, I'm not trying to force > > anything in. ;) > > Agreed. > > I cobbled something up yesterday that saves the directory tree state of > /var/run prior to shutdown (or manually) and restores it at boot. > > https://reviews.freebsd.org/D36386 > > People can try it out if they want. If there's enough interest I'd be > willing to commit it. > > We have a few options on the table and probably more. The ports > infrastructure option is probably the most work. Adding functionality to > all the ports that use /var/run is also a lot of work and if relying on > individual porters, will likely take some time and be varied in > implementation and robustness. > > I'd like to add a sidenote here, if one may please. 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. On the other hand, there are only few ports which create subfolders to, i.e., /var/run not congruent what the specific metree sketch implies, the port security/clamav is one of those few. The question that bothers me most and this is just from the pratical point of view as stated initially and from a second view, just out of curiosity: 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? -- O. Hartmann