Re: security/clamav: /ar/run on TMPFS renders the port broken by design
In message <20220828130107.1a76d54a.gre...@freebsd.org>, Michael Gmelin writes: > > > > On Sun, 28 Aug 2022 03:21:24 -0700 > Cy Schubert wrote: > > > In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>, > > Michael Gmelin w > > rites: > > > > > > > > > > > > > On 28. Aug 2022, at 10:42, free...@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 FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
On Sun, 28 Aug 2022 03:21:24 -0700 Cy Schubert wrote: > In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>, > Michael Gmelin w > rites: > > > > > > > > > On 28. Aug 2022, at 10:42, free...@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 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. 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. This is meant to inspire more discussions, I'm not trying to force anything in. ;) Cheers Michael -- Michael Gmelin
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>, Michael Gmelin w rites: > > > > > On 28. Aug 2022, at 10:42, free...@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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
In message <202208280842.27s8gdxn055...@nuc.oldach.net>, Helge Oldach
writes:
> Cy 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.
>
> Not supported? What is the purpose of /etc/rc.d/var then? That creates a tmpf
> s backed /var, populates it through mtree, and makes a proper /var/run availa
> ble.
>
> However it doesn't (yet) create /var/run/clamav of course.
>
> It would be fairly easy to extend /etc/rc.d/var by a logic that walks through
> /usr/local/etc/mtree/* and runs mtree on each of the files found as needed.
> All that the security/clamav port would need to do then is to drop an appropr
> iate small mtree file as /usr/local/etc/mtree/clamav. From a port's perspecti
> ve that is the same logic as dropping service scripts as /usr/local/etc/rc.d/
> clamav-*.
>
> Kind regards
> Helge
This is because you don't already have a /var/run/clamav yet. Unfortunately
this dies not retroactively create /var/run/clamav.
My new copy of the script, attached, also does not retroactively create the
directory. Create the directory by hand. Use your server. Reboot and the
directories will be recreated.
If converting from UFS or ZFS /var/run, simply add the tmpfs mountpoint
after adding and enabling the script and reboot. (I prefix all locally
written scripts with kq-).
Remember, this does not retroactively create /var/run/clamav if it doesn't
already exist. This only makes mounting of tmpfs /var/run an option
possible.
#!/bin/sh
# PROVIDE: kq-var-run
# REQUIRE: zfs tmp
# BEFORE: FILESYSTEMS
. /etc/rc.subr
name=kq_var_run
rcvar=kq_var_run_enable
extra_commands="load save"
start_cmd="kq_var_run_start"
load_cmd="kq_var_run_load"
save_cmd="kq_var_run_save"
stop_cmd="kq_var_run_stop"
load_rc_config $name
# Set defaults
: ${kq_var_run_enable:="NO"}
: ${kq_var_run_mtree:="/var/db/mtree/BSD.var-run.mtree"}
: ${kq_var_run_autosave:="YES"}
kq_var_run_load() {
test -f ${kq_var_run_mtree} &&
mtree -U -i -q -f ${kq_var_run_mtree} -p /var/run > /dev/null
}
kq_var_run_save() {
if [ ! -d $(dirname ${kq_var_run_mtree}) ]; then
mkdir -p ${kq_var_run_mtree}
fi
mtree -dcbj -p /var/run > ${kq_var_run_mtree}
}
kq_var_run_start() {
df -ttmpfs /var/run > /dev/null 2>&1 &&
kq_var_run_load
}
kq_var_run_stop() {
df -ttmpfs /var/run > /dev/null 2>&1 &&
checkyesno kq_var_run_autosave &&
kq_var_run_save
}
run_rc_command "$1"
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
On Sun, 28 Aug 2022 11:37:16 +0200 Michael Gmelin wrote: > > On 28. Aug 2022, at 10:42, free...@oldach.net wrote: > > > > Cy 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. > > > > Not supported? What is the purpose of /etc/rc.d/var then? That > > creates a tmpfs backed /var, populates it through mtree, and makes > > a proper /var/run available. > > > > However it doesn't (yet) create /var/run/clamav of course. > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that > > walks through /usr/local/etc/mtree/* and runs mtree on each of the > > files found as needed. All that the security/clamav port would need > > to do then is to drop an appropriate small mtree file as > > /usr/local/etc/mtree/clamav. From a port's perspective that is the > > same logic as dropping service scripts as > > /usr/local/etc/rc.d/clamav-*. > > From a user's perspective, it would be preferable to have this happen > at service start though, as (unlike in the setup described) reboots > don't happen that frequently, but files in /var/run might get deleted > manually. Maybe some rc framework based solution would make sense, > e.g., a variable `mtree_files`, which, if set, is applied in the > default start_precmd. Besides being more resilient, this would also > have the advantage that all required file systems should be available > at that point and the separation between system and ports would be > more clear. Another advantage would be that directories are only > created for services that are actually enabled/started. Yes, something in the RC framework would be nice.
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 28. Aug 2022, at 10:42, free...@oldach.net wrote: > > Cy 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. > > Not supported? What is the purpose of /etc/rc.d/var then? That creates a > tmpfs backed /var, populates it through mtree, and makes a proper /var/run > available. > > However it doesn't (yet) create /var/run/clamav of course. > > It would be fairly easy to extend /etc/rc.d/var by a logic that walks through > /usr/local/etc/mtree/* and runs mtree on each of the files found as needed. > All that the security/clamav port would need to do then is to drop an > appropriate small mtree file as /usr/local/etc/mtree/clamav. From a port's > perspective that is the same logic as dropping service scripts as > /usr/local/etc/rc.d/clamav-*. From a user's perspective, it would be preferable to have this happen at service start though, as (unlike in the setup described) reboots don't happen that frequently, but files in /var/run might get deleted manually. Maybe some rc framework based solution would make sense, e.g., a variable `mtree_files`, which, if set, is applied in the default start_precmd. Besides being more resilient, this would also have the advantage that all required file systems should be available at that point and the separation between system and ports would be more clear. Another advantage would be that directories are only created for services that are actually enabled/started. Cheers Michael
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
In message <20220827082638.57901a72@slippy>, Cy Schubert writes:
> 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, free...@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
> > o...@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.
This will resolve the problem:
#!/bin/sh
# PROVIDE: kq-var-run
# REQUIRE: zfs tmp
# BEFORE: FILESYSTEMS
. /etc/rc.subr
name=kq_var_run
rcvar=kq_var_run_enable
extra_commands="update create"
start_cmd="kq_var_run_start"
create_cmd="kq_var_run_create"
update_cmd="kq_var_run_create"
# stop_cmd="kq_var_run_create"
load_rc_config $name
# Set defaults
: ${kq_var_run_enable:="NO"}
: ${kq_var_run_mtree:="/etc/local/mtree/KQ.var-run.mtree"}
kq_var_run_start() {
df -ttmpfs /var/run > /dev/null 2>&1 &&
mtree -f ${kq_var_run_mtree} -p /var/run
}
kq_var_run_create() {
mtree -cbdj -p /var/run > ${kq_var_run_mtree}
}
run_rc_command "$1"
A person could add stop_cmd="kq_var_run_create" to save the /var/run mtree
at shutdown instead of manually. Works with tmpfs /var/run.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
On Sat, 27 Aug 2022 15:38:44 +0200 Juraj Lutter wrote: > > On 27 Aug 2022, at 15:27, Michael Gmelin wrote: > > > > > > > >> On 27. Aug 2022, at 15:18, free...@oldach.net wrote: > >> > >> Michael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST): > >>> (you're removing /var/run, which shouldn't be removed > >> > >> Not quite. It's actually not uncommon to boot with an empty /var. Please > >> see /etc/rc.d/var and related. > > > > That’s a good point. > > > >> The request that ports/packages should consider this case is not exactly > >> unreasonable IMO. > >> > > > > If I was the maintainer, I would simply add the code to create the > > directory 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 > > correct permissions are applied). But since it doesn’t seem like this is > > going to happen, adding a custom rc file would be a viable short term > > workaround for the requester. > > > > I like the idea of having something like tmpfiles.d, it would also help > > port maintainers (could also be done as a port). > > > > As I have stated in one of those PR: clamd creates file in two locations: > > - PidFile > - LocalSocket > > Both the locations could be checked by rc.d script in clamd.conf (also > freshclam eventually) and respective directories can be created from within > start_precmd() > > otis > > — > Juraj Lutter > o...@freebsd.org > 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. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Michael Gmelin wrote: > I like the idea of having something like tmpfiles.d, it would also help port > maintainers (could also be done as a port). I use tmpfs for /var/run and already have such a script for this very reason (although not clamav) I would have thought each port startup script should ensure it's file/directory exists before attempting to launch - having "tmpfiles.d" would still require some changes for the port maintainer to make to their port, but I guess it may help to keep things centralised. I'm willing to "standardise" my script if it would help, but as it stands, you can see it here: http://freebsd.dyslexicfish.net/src/ 15:47 (71) "~/x" jamie@newbie% cat /usr/common/etc/var_run.mtree # File/DirectoryUser GroupPerms # distccd.pid distcc distcc 640 ntop/ ntop ntop 750 nsd/nsdnsd750 netdata/netdatanetdata750 screens/root wheel 1777 sshdbanner/ sshdbanner sshdbanner 755 spamd/ spamd spamd 750 symon.pid _symon _symon 640 symux.pid _symon _symon 640 vnstat/ vnstat vnstat 750
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 27 Aug 2022, at 15:27, Michael Gmelin wrote: > > > >> On 27. Aug 2022, at 15:18, free...@oldach.net wrote: >> >> Michael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST): >>> (you're removing /var/run, which shouldn't be removed >> >> Not quite. It's actually not uncommon to boot with an empty /var. Please see >> /etc/rc.d/var and related. > > That’s a good point. > >> The request that ports/packages should consider this case is not exactly >> unreasonable IMO. >> > > If I was the maintainer, I would simply add the code to create the directory > 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 correct > permissions are applied). But since it doesn’t seem like this is going to > happen, adding a custom rc file would be a viable short term workaround for > the requester. > > I like the idea of having something like tmpfiles.d, it would also help port > maintainers (could also be done as a port). > As I have stated in one of those PR: clamd creates file in two locations: - PidFile - LocalSocket Both the locations could be checked by rc.d script in clamd.conf (also freshclam eventually) and respective directories can be created from within start_precmd() otis — Juraj Lutter o...@freebsd.org
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 27. Aug 2022, at 15:18, free...@oldach.net wrote: > > Michael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST): >> (you're removing /var/run, which shouldn't be removed > > Not quite. It's actually not uncommon to boot with an empty /var. Please see > /etc/rc.d/var and related. That’s a good point. > The request that ports/packages should consider this case is not exactly > unreasonable IMO. > If I was the maintainer, I would simply add the code to create the directory 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 correct permissions are applied). But since it doesn’t seem like this is going to happen, adding a custom rc file would be a viable short term workaround for the requester. I like the idea of having something like tmpfiles.d, it would also help port maintainers (could also be done as a port). Cheers
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Am Sat, 27 Aug 2022 13:16:43 +0200 tue...@freebsd.org schrieb: > > On 27. Aug 2022, at 08:30, FreeBSD User 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. > Why are you rebooting every 24 hours? The appliance has to be on a non-writable medium and is to be rebooted every 24 hours to cleanse temporary memory. This is given in the specs and by the department(s) the appliance is for. Kind regards > > Best regards > Michael > > > > 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, > > > > kind regards > > > > O. Hartmann > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585 > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699 > > > > > > -- > > O. Hartmann > > > > -- O. Hartmann
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 27. Aug 2022, at 12:54, FreeBSD User wrote: > > Am Sat, 27 Aug 2022 11:21:40 +0200 > Michael Gmelin schrieb: > On 27. Aug 2022, at 08:31, FreeBSD User 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
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 27. Aug 2022, at 08:30, FreeBSD User 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. Why are you rebooting every 24 hours? Best regards Michael > > 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, > > kind regards > > O. Hartmann > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585 > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699 > > > -- > O. Hartmann >
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Am Sat, 27 Aug 2022 11:21:40 +0200 Michael Gmelin schrieb: > > On 27. Aug 2022, at 08:31, FreeBSD User 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? Best regards, oh -- O. Hartmann
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
> On 27. Aug 2022, at 08:31, FreeBSD User 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
Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Hello, Maybe you can use a shell script that creates the directory with @reboot at cron. If this doesn't work (not sure if clamav starts before cron), then maybe you can use monit to create the directory and start clamav. Kind regards, Christos Chatzaras > On 27 Aug 2022, at 09:30, FreeBSD User 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, > > kind regards > > O. Hartmann > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585 > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699 > > > -- > O. Hartmann >
security/clamav: /ar/run on TMPFS renders the port broken by design
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, kind regards O. Hartmann [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699 -- O. Hartmann
