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

[Andrey V. Elsukov]

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

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20191218/12e2f516/attachment.sig>