svn commit: r343631 - in head: . sbin sbin/pfilctl share/man/man9 sys/contrib/ipfilter/netinet sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw sys/netpfil/pf

[Gleb Smirnoff]

On Wed, Dec 18, 2019 at 03:27:58PM +0300, Andrey V. Elsukov wrote:
A> > Log:
A> >   New pfil(9) KPI together with newborn pfil API and control utility.
A> >   
A> >   The KPI have been reviewed and cleansed of features that were planned
A> >   back 20 years ago and never implemented.  The pfil(9) internals have
A> >   been made opaque to protocols with only returned types and function
A> >   declarations exposed. The KPI is made more strict, but at the same time
A> >   more extensible, as kernel uses same command structures that userland
A> >   ioctl uses.
A> >   
A> >   In nutshell [KA]PI is about declaring filtering points, declaring
A> >   filters and linking and unlinking them together.
A> >   
A> >   New [KA]PI makes it possible to reconfigure pfil(9) configuration:
A> >   change order of hooks, rehook filter from one filtering point to a
A> >   different one, disconnect a hook on output leaving it on input only,
A> >   prepend/append a filter to existing list of filters.
A> >   
A> >   Now it possible for a single packet filter to provide multiple rulesets
A> >   that may be linked to different points. Think of per-interface ACLs in
A> >   Cisco or Juniper. None of existing packet filters yet support that,
A> >   however limited usage is already possible, e.g. default ruleset can
A> >   be moved to single interface, as soon as interface would pride their
A> >   filtering points.
A> >   
A> >   Another future feature is possiblity to create pfil heads, that provide
A> >   not an mbuf pointer but just a memory pointer with length. That would
A> >   allow filtering at very early stages of a packet lifecycle, e.g. when
A> >   packet has just been received by a NIC and no mbuf was yet allocated.
A> It seems that this commit has changed the error code returned from
A> ip[6]_output() when a packet is blocked. Previously it was EACCES, but
A> now it became EPERM. Was it intentional?

I don't think that was intentional. Can you please review this patch?

-- 
Gleb Smirnoff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EACCES.diff
Type: text/x-diff
Size: 1531 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20191220/500dc218/attachment.diff>