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

[Cy Schubert]

On December 18, 2019 4:27:58 AM PST, "Andrey V. Elsukov" <bu7cher at yandex.ru> wrote:
>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?

EPERM, operation not permitted regardless of privilege, is more appropriate. 


-- 
Pardon the typos and autocorrect, small keyboard in use. 
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: https://www.FreeBSD.org

The need of the many outweighs the greed of the few.

Sent from my Android device with K-9 Mail. Please excuse my brevity.