Delition of rule after altering data in check/match entry

Delition of rule after altering data in check/match entry

[Sumit Pandya]

Hi All,
    In a netfilter match or check extension at the time of rule-insertion,
If I update any data passed along
    1> void *matchinfo (argument to matchentry) or
    2> void *targinfo  (argument to checkentry)
Then I'm not able to delete same inserted rule.
    Is there something regarding caching of the data? Does It require to
notify iptables somewhere about this change?
Thanks,
-- Sumit

Re: Delition of rule after altering data in check/match entry

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Mon, Jul 14, 2003 at 09:01:22PM +0530, Sumit Pandya wrote:
> Hi All,
>     In a netfilter match or check extension at the time of rule-insertion,
> If I update any data passed along
>     1> void *matchinfo (argument to matchentry) or
>     2> void *targinfo  (argument to checkentry)
> Then I'm not able to delete same inserted rule.
>     Is there something regarding caching of the data? Does It require to
> notify iptables somewhere about this change?

Just at first glance, I think this is quite possible (and certainly not
the desired behaviour).   Can you please verify that this bug is also
present with already-existing matches/targets that change
targinfo/matchinfo contents (like the nth or random match)?

If so, please commit this as a bug report to bugzilla.netfilter.org.

> Thanks,
> -- Sumit

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Delition of rule after altering data in check/match entry

[Sumit Pandya]

Hi Harald,
    Thanks for reply. I'm sorry that without thorough study of nice document
netfilter-hacking-HOWTO I posted this as a problem. I seen ipt_limit as
reference and problem fixed.

static
struct iptables_match problem_foo = {
        NULL,
        "foo",
        NETFILTER_VERSION,
        IPT_ALIGN(sizeof(struct ipt_foo_target_info)),
        IPT_ALIGN(sizeof(struct ipt_foo_target_info) - sizeof(struct
__kern_set)),
        &help,
        &init,
        &parse,
        &final,
        &print,
        &save,
        opts
};
static
struct iptables_match right_foo = {
        NULL,
        "foo",
        NETFILTER_VERSION,
        IPT_ALIGN(sizeof(struct ipt_foo_target_info)),
        offsetof(struct ipt_foo_target_info, kern_set),
        &help,
        &init,
        &parse,
        &final,
        &print,
        &save,
        opts
};

----- Original Message -----
From: "Harald Welte" <laforge@netfilter.org>
Sent: Tuesday, July 15, 2003 5:58 PM

On Mon, Jul 14, 2003 at 09:01:22PM +0530, Sumit Pandya wrote:
> Hi All,
>     In a netfilter match or check extension at the time of rule-insertion,
> If I update any data passed along
>     1> void *matchinfo (argument to matchentry) or
>     2> void *targinfo  (argument to checkentry)
> Then I'm not able to delete same inserted rule.
>     Is there something regarding caching of the data? Does It require to
> notify iptables somewhere about this change?

Just at first glance, I think this is quite possible (and certainly not
the desired behaviour).   Can you please verify that this bug is also
present with already-existing matches/targets that change
targinfo/matchinfo contents (like the nth or random match)?