Re: security/clamav: /ar/run on TMPFS renders the port broken by design
- In reply to: FreeBSD User : "Re: security/clamav: /ar/run on TMPFS renders the port broken by design"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 27 Aug 2022 13:02:04 UTC
> On 27. Aug 2022, at 12:54, FreeBSD User <freebsd@walstatt-de.de> wrote: > > Am Sat, 27 Aug 2022 11:21:40 +0200 > Michael Gmelin <grembo@freebsd.org> schrieb: > >>>> On 27. Aug 2022, at 08:31, FreeBSD User <freebsd@walstatt-de.de> wrote: >>> >>> Hello, >>> >>> I'm referencing to Bug 259699 [2] and Bug 259585 [1]. >>> >>> Port security/clamav is without doubt for many of FreeBSD users an important piece of >>> security software so I assume a widespread usage. >>> >>> It is also a not uncommon use case to use NanoBSD or any kind of low-memory-footprint >>> installation schemes in which /var/run - amongst other system folders - are created at boot >>> time as TMPFS and highly volatile. >>> >>> In our case, the boxes running a small security appliance based upon FreeBSD is rebooted >>> every 24 hours and so /var/run is vanishing. >>> >>> To make the long story short: >>> >>> The solution for this problem would be a check for existence and take action addendum in >>> precmd() routine of the rc-script as sketched in Bug 259699. >>> The maintainer rejects such a workaround by arguing this would violate POLA (see comment 4 >>> in PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound to me. >>> >>> The question is: how can this issue be solved? >>> >>> It is really hard to always chenge our local repository and patch whenever clamav has been >>> patched and modified for what reason ever. >>> >>> Tahanks for reading, >>> >> >> Why don’t you simply add an rc script to your appliance that creates the missing >> directory/directories on boot before clamav is started? >> >> Best >> Michael >> >> >> > > Why not fixing this on a more general basis? It‘s a reasonable way forward, given the limitations you described (you’re removing /var/run, which shouldn’t be removed and the port maintainer not willing to add code to compensate for this). This would fix it for you for your specific needs in a reliable way, you would never have to patch the port again and also won’t use other people‘s time to find a general solution to your very specific problem. It’s a sustainable quick fix to your problem at hand. You can always come up with something grand later, but this would actually work right away. Cheers