Setting aside pflog, I still think there may have been an error
introduced in revision 1.2, as I stated in my bug description below.
Unless "rc_pre" works in a way that I don't understand, the first line
of the rc_pre function in rc.d/spamlogd is an error; it's an unchecked
condition.
Here's a patch to explain:
--- spamlogd,v 1.4
+++ spamlogd-patch Sun Apr 3 01:04:16 2022
@@ -9,11 +9,14 @@
rc_reload=NO
rc_pre() {
- [[ ${spamd_flags} != NO && ${spamd_black} == NO ]]
- if pfctl -si | grep -q Enabled; then
- ifconfig pflog0 create
- if ifconfig pflog0; then
- ifconfig pflog0 up
+ if [[ ${spamd_flags} != NO && ${spamd_black} == NO ]]; then
+ if pfctl -si | grep -q Enabled; then
+ ifconfig pflog0 create
+ if ifconfig pflog0; then
+ ifconfig pflog0 up
+ else
+ return 1
+ fi
else
return 1
fi
On Wed, 30 Mar 2022 11:57:49 -0600
"Theo de Raadt" <[email protected]> wrote:
> Right. However, this was discussed before that there is a wierdness
> here -- the spam tools assume they get that pflog interface, but there
> are other usage cases where that would be wrong. We didn't find a
> clean solution for making spamlogd use a unique interface last time we
> discussed this.
>
>
> Stuart Henderson <[email protected]> wrote:
>
> > I think the intent is that the pflog interface gets created in case
> > pflogd is disabled (which is a perfectly valid configuration)
> >
> > --
> > Sent from a phone, apologies for poor formatting.
> >
> > On 30 March 2022 07:53:39 [email protected] wrote:
> >
> > >> Synopsis: rc_pre() not properly checking spamd rc variables
> > >> Category: system
> > >> Environment:
> > > System : OpenBSD 7.0
> > > Details : OpenBSD 7.0 (GENERIC.MP) #5: Mon Jan 31 09:09:02
> > > MST 2022
> > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > >> Description:
> > > In revision 1.1 of /etc/rc.d/spamlogd, the rc_pre() function
> > > ensures that spamd is enabled and not operating in blacklist-only
> > > mode. Perfect.
> > >
> > > However, revision 1.2 introduced a bug when the code to create
> > > the pflog0 interface was added. Checking whether spamd is enabled
> > > or not is essentially ignored.
> > >
> > >> Fix:
> > > The creation of the pflog0 interface should not be done in
> > > rc.d/spamlogd because the interface is already created in
> > > rc.d/pflogd (it's the exact same in fact). This seems reasonable
> > > because pflogd is enabled by default and starts before spamlogd.
> > >
> > > Instead, rc.d/spamlogd should just check the pflogd flag along
> > > with the spamd flags.
> > >
> > >
> > > --- spamlogd,v 1.4
> > > +++ /tmp/spamlogd Thu Mar 24 04:26:16 2022
> > > @@ -9,17 +9,7 @@
> > > rc_reload=NO
> > >
> > > rc_pre() {
> > > - [[ ${spamd_flags} != NO && ${spamd_black} == NO ]]
> > > - if pfctl -si | grep -q Enabled; then
> > > - ifconfig pflog0 create
> > > - if ifconfig pflog0; then
> > > - ifconfig pflog0 up
> > > - else
> > > - return 1
> > > - fi
> > > - else
> > > - return 1
> > > - fi
> > > + [[ ${spamd_flags} != NO && ${spamd_black} == NO &&
> > > ${pflogd_flags} != NO ]] }
> > >
> > > rc_cmd $1
> >
