Re: [PATCH] nwfilter: Deactivate iptables MAC address check where needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Blake <eblake@xxxxxxxxxx> wrote on 03/10/2014 06:05:18 PM:

> From: Eric Blake <eblake@xxxxxxxxxx>


> On 03/10/2014 02:49 PM, Stefan Berger wrote:
> > From: Stefan Berger <stefanb@xxxxxxxxxxxxxxxxxx>
> >
> > Recent Linux iptables (3.11.7) refuses to create iptables MAC address
> > check rules using -m mac --mac-source <addr> where previous versions
> > still allowed it. So we now need to deactivate the filtering rules for
> > when the incoming traffic is filtered before it is sent into the VM.
> > Those are typically the chains that start with FO-* or start with FP-*
> > when they are being built.
> >
> > Adapt the documentation to reflect the fact that srcmacaddr, when
> > used in iptables rules, should be regarded as deprecated due to the
> > above mentioned problems.
>
> Is this an unintentional kernel regression, or something that we were
> doing wrong all along and the kernel is now finally calling our bluff?


I must say, I did not test whether the iptables rule in this particular case
did not work. I assumed that if it applies, it will work. And besides that
it is supposed to work in the FORWARD chain (following dmesg) and we now have
a case where the rule is accepted in a chain that is connected to the FORWARD
chain and is rejected in a chain that is also connected to the FORWARD chain.
Both chains are not connected to the FORDWARD chain directly but there is one
other chain in between. It may be that iptables walks these chains to see whether
they are connected to the FORWARD chain but for some reason doesn't do it
correctly for the 2nd case.

It still applies in 3.10.

>
>
> > +++ b/docs/formatnwfilter.html.in
> > @@ -1209,7 +1209,7 @@
> >         <tr>
> >           <td>srcmacaddr</td>
> >           <td>MAC_ADDR</td>
> > -         <td>MAC address of sender</td>
> > +         <td>MAC address of sender; this option is deprecated</td>
>
> Marking something as deprecated is one thing...
>
> >         </tr>
> >         <tr>
> >           <td>srcipaddr</td>
> > @@ -1320,22 +1320,7 @@
> >         <tr>
> >           <td>srcmacaddr</td>
> >           <td>MAC_ADDR</td>
> > -         <td>MAC address of sender</td>
> > -       </tr>
> > -       <tr>
> > -         <td>srcmacmask</td>
> > -         <td>MAC_MASK</td>
> > -         <td>Mask applied to MAC address of sender</td>
> > -       </tr>
>
> ...but completely removing documentation feels wrong.  Was this bogus
> documentation, or do we still support usage of this XML on older kernels
> that don't prohibit it?  Maybe separate this into multiple patches - doc


This was bogs documentation. Must have been a c&p error. srcmacmask only exists for rules mapping into ebtables rules, but that's not the case here.

> fixes (deleting stuff that never worked) vs. deprecation (marking stuff
> that no longer works on newer kernels).
>
> > @@ -984,6 +984,14 @@ iptablesHandleSrcMacAddr(virBufferPtr buf,
> >              return 0;
> >          }
> >  
> > +        /* recent Linux iptables does not allow this filteirng rule to be
>
> s/filteirng/filtering/
>
> > +         * applied to all FO-* chains
> > +         */
> > +        if (chain[1] == CHAINPREFIX_HOST_OUT_TEMP ) {
>
> No space before )
>


Will fix.

Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]