Huh. Interesting. The IP_FW_ADD test threw me but now that I
look at the code more closely it is only there because IP_FW_ADD
is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends
are SOPT_SET only. Now I see how it works :-)
-Matt
:..
:: rule that, say, prevents spoofing is as bad as adding a rule that
:: allows everything through :-(
:
:This comment got me thinking. The thinking lead to a lot of looking
:at code between compiles today, and more this evening. It would
:appear that the test that was there was sufficient to deal with the
:cases that I was worried about. Revisiting the change:
:
:- if (sopt->sopt_name == IP_FW_ADD ||
:+ if (sopt->sopt_name == IP_FW_ADD || sopt->sopt_name == IP_FW_UNBREAK ||
: (sopt->sopt_dir == SOPT_SET && sopt->sopt_name != IP_FW_RESETLOG)) {
:
:Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
:SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
:requests. Since GET + ADD is only case that isn't a SET that changes
:things, the == SOPT_SET takes care of the case that you added.
:
:For a while I thought one could do nasty things based on GET + FLUSH,
:say, but in raw_ip.c, we do the proper checks before calling
:ip_fw_ctl_ptr().
:
:So it looks like this code is subtle enough to have fooled both of
:us. This one change isn't needed for this patch.
:
:Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
