From nobody Sat Aug 27 15:26:38 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 4MFLCR1t2Bz4ZdM1; Sat, 27 Aug 2022 15:26:43 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFLCQ2m7wz3fSk; Sat, 27 Aug 2022 15:26:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id RvtbosFtJSp39RxhpoPmey; Sat, 27 Aug 2022 15:26:41 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id Rxhmou3jEGRNlRxhnoi1bT; Sat, 27 Aug 2022 15:26:41 +0000 X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=630a37b1 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=gRS1eiuiAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=R0zMgeHHeiDL7zLRjdsA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=udpbrAo2yJH2O6eCpvBn:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 735AB1594; Sat, 27 Aug 2022 08:26:38 -0700 (PDT) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 5FB1C2B0; Sat, 27 Aug 2022 08:26:38 -0700 (PDT) Date: Sat, 27 Aug 2022 08:26:38 -0700 From: Cy Schubert To: Juraj Lutter , freebsd@walstatt-de.de Cc: Michael Gmelin , freebsd@oldach.net, freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by design Message-ID: <20220827082638.57901a72@slippy> In-Reply-To: References: <202208271318.27RDI9Jd044045@nuc.oldach.net> Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfPeqJGiz1ILL44o16BHcK03y4P02Pe9qa2bhtGnNq4DSj7sKNE4SmgwofQS1VGQUMjdzyYAx3SkXl68WQlqjcU2zblfebScneknX5OU3Fo/NI38VVHTp j/N/mIiyCmRsiJntK2O+9vvLHAvf6pcpHaygPsg/jGnptac4AxAxthbi514ETCUBUJNDBZL6Z9RbvV+4apRHEuT2mXNABAZvxR5VFgxrCi8dAv0B9f5wuxQo kJin//oJ9Jxoiy5x4h81ILInfyaPd09FoXsBE7oBnJMOQGesVxSjXFs5VTa8NUSj9bJD36GEJL4gWqjHz6SkxgmStwNZyFCC6xSgfh1oYbVHGkMCj5GXesiQ blEQhyH+wnVIHWekqkSzcSqV6azuDiyiBXxSZtV1sLsMpEI86ZU= X-Rspamd-Queue-Id: 4MFLCQ2m7wz3fSk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.79 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_COUNT_FIVE(0.00)[5]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 27 Aug 2022 15:38:44 +0200 Juraj Lutter wrote: > > On 27 Aug 2022, at 15:27, Michael Gmelin wrote: > >=20 > >=20 > > =20 > >> On 27. Aug 2022, at 15:18, freebsd@oldach.net wrote: > >>=20 > >> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST= ): =20 > >>> (you're removing /var/run, which shouldn't be removed =20 > >>=20 > >> Not quite. It's actually not uncommon to boot with an empty /var. Plea= se see /etc/rc.d/var and related. =20 > >=20 > > That=E2=80=99s a good point. > > =20 > >> The request that ports/packages should consider this case is not exact= ly unreasonable IMO. > >> =20 > >=20 > > If I was the maintainer, I would simply add the code to create the dire= ctory for robustness sake (I for one deleted subdirs in /var/run more than = once and would expect a port to fix this on restart, also to make sure corr= ect permissions are applied). But since it doesn=E2=80=99t seem like this i= s going to happen, adding a custom rc file would be a viable short term wor= karound for the requester. > >=20 > > I like the idea of having something like tmpfiles.d, it would also help= port maintainers (could also be done as a port). > > =20 >=20 > As I have stated in one of those PR: clamd creates file in two locations: >=20 > - PidFile > - LocalSocket >=20 > Both the locations could be checked by rc.d script in clamd.conf (also fr= eshclam eventually) and respective directories can be created from within s= tart_precmd() >=20 > otis >=20 > =E2=80=94 > Juraj Lutter > otis@FreeBSD.org >=20 As stated before in this thread, replacing /var/run with tmpfs is not a supported configuration. However if users wish to replace /var/run with tmpfs they can create an rc script (I put my extra rc scripts in /etc/local/rc.d) to create the hierarc If one does this they can either use mtree(1) to create the hierarchy or simply take a snapshot (find /var/run -type d | cpio -o > /etc/local/my_var_run.cpio), having their rc script recreate the hierarchy using cpio -i < /etc/local/my_var_run.cpio). And be periodically updated the archive as needed, probably through a shutdown script. One will notice that /etc/mtree/BSD.var.dist shows us what is created in /var/run by default during installworld. The change requested is not specifically for an individual port but essentially a FreeBSD-wide infrastructure change. I don't think this is reasonable without a lot of consideration about what will be broken during the process of changing build and boot processes and the potential POLA fallout from such a change. A change like this needs to be architected. I don't think this is the mailing list to discuss this topic. This should be discussed on ports@. Not here. Maybe it should be moved there as this is a ports not a base O/S issue. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0