Date: Sun, 28 Aug 2022 06:11:20 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Michael Gmelin <grembo@freebsd.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, freebsd@oldach.net, otis@freebsd.org, freebsd@walstatt-de.de, 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: <20220828131120.C3781317@slippy.cwsent.com> In-Reply-To: <20220828130107.1a76d54a.grembo@freebsd.org> References: <202208280842.27S8gDXn055868@nuc.oldach.net> <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> <20220828102124.409EC26D@slippy.cwsent.com> <20220828130107.1a76d54a.grembo@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin writes: > > > > On Sun, 28 Aug 2022 03:21:24 -0700 > Cy Schubert <Cy.Schubert@cschubert.com> 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. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220828131120.C3781317>