Re: [PATCH] netfilter/nflog: nflog-range does not truncate packets

[Vishwanath Pai <vpai@akamai.com>]

On 06/17/2016 07:22 AM, Pablo Neira Ayuso wrote:
> On Wed, Jun 15, 2016 at 03:13:15PM +0000, Lubashev, Igor wrote:
>> Vish, Pablo,
>>
>> I wonder about the value of sending more data than a client is
>> willing to consume (setting aside the important fact that the client
>> code crashes due to the extra data).
>>
>> It seems that we should either drop the nflog-range parameter from
>> nflog altogether (and just use the len from the client) or allow
>> nflog-range to further *restrict* the number of bytes sent to the
>> client.
>>
>> The "further restrict" logic would make it easier to build iptables
>> rules that vary nflog-range based on some match conditions, so a
>> single client would get different packet length depending on what
>> rules matched.
> 
> Now I understand your usecase. Restricting the size based on match
> conditions sound reasonable to me.
> 
> Why don't you add a new userspace option, eg. --nflog-size, that
> specifies this "further restrict" logic?
> 
> What I'm proposing is:
> 
> 1) If --nflog-range is used, print a message telling: "--nflog-range
>    has never worked, ignoring this option."
> 
> 2) If --nflog-size is used, set the size in the structure that is
>    passed to the kernel, and apply this "further restrict" logic.
> 
> 3) Add the flag to the kernel that I suggested. This flag is only set
>    via --nflog-size.
> 
> Just to clarify: What I'm trying to avoid is breaking the thing for
> users that are using this --nflog-range (even if it doesn't work) and
> then change the behaviour for them.
> 
> With the new option, we really validate that the user is exactly
> asking for this "further restrict" logic that you need.
> 
> let me know, thanks.
> 

Sounds good to me, yes it will definitely change the behavior for users
who are using that parameter (whether intentional or not). I'm OK with
adding a new parameter instead of using --nflog-range. I will send a
patch with these changes.