On Sunday 2009-11-29 12:33, Adam Nielsen wrote:
>>> static bool led_tg_check(const struct xt_tgchk_param *par)
>>> {
>>> struct xt_led_info *ledinfo = par->targinfo;
>>> - struct xt_led_info_internal *ledinternal;
>>> + struct xt_led_info_internal *ledinternal = ledinfo->internal_data;
>>> int err;
>>
>> You cannot rely on ledinfo->internal_data having any meaningful
>> value when iptables prepares the rule.
>
> Hmm ok, so in led_tg_check (the .checkentry function) how do you tell whether
> the xt_tgchk_param is pointing to an existing ruleset or not? Or is it always
> referring to a new ruleset and you have to handle it yourself?
You always have to do a lookup on some structure that has xt_LED.ko
lifetime (similar to what xt_recent/xt_rateest does).
> I guess my question comes from this point of view:
>
> $ iptables -A scroll_lock -j LED --led-trigger-id http
>
> This calls led_tg_check() with a new xt_tgchk_param structure.
>
> $ iptables -I INPUT 1 -p tcp --sport 80 -j scroll_lock
>
> Now led_tg_check() gets called again with an xt_tgchk_param structure
> containing the trigger name etc. even though this was not specified on the
> command line. Where does that second xt_tgchk_param come from if it's not a
> pointer to the first one?
Running two iptables instances concurrently. Even without races like
these, it would be a security violation to accept unknown pointers from
userspace.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
