bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"

[Alexander Verbod]

The following reply was made to PR bin/153252; it has been noted by GNATS.

From: "Alexander Verbod" <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF at gmx.com>
To: bug-followup at FreeBSD.org
Cc:  
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call
 of "/etc/rc.d/ipfw start"
Date: Sat, 18 Dec 2010 15:00:01 -0500

 --========GMX20051292702401607924
 Content-Type: text/plain; charset="utf-8"
 Content-Transfer-Encoding: 8bit
 
 Eugene Grosbein <eugen at grosbein.pp.ru> wrote:
 
 > One should not unconditionally disable ability of reloading ipfw rules
 > using "/etc/rc.d/ipfw start" command.
 
 Patch  doesn't "unconditionally disable ability of reloading ipfw rules"!
 Patch disables the ability to run start up script "/etc/rc.d/ipfw"
 with "start" command twice that causes lockdown even if type of firewall
 is "OPEN".
 
 By the term "reloading" I guess you meant the "restart" command
 that's doing stop/start sequence, but not start/start. ;)
 
 > For example, it's used extensively
 > in my systems and does not lead to "lock-down".
 
 Eugene, you could do with your systems whatever you want, but here was 
 described the bug that appears when used standard, non modified OS.
 
 Did you try all steps described in the "How-To-Repeat" section before replying?
 
 
 > One should learn ipfw(8) manual page including CHECKLIST paragraph
 
 :) 
 
 Could you check please /etc/rc.firewall for presence of this line
 "${fwcmd} add 65000 pass all from any to any"
 It's the only one line for "OPEN" firewall's profile.
 
 One who claim to know ipfw(8) manual page should understand this
 firewall's rule that unconditionally allow all traffic in both direction for any
 type of protocols. But after running "/etc/rc.d/ipfw start" twice all rules are
 flashed and only default rule: 
 65535 deny ip from any to any
 to take affect.
 
 
 > and make oneself familiar with proper ways of reloading ipfw over
 > network.
 
 Did I say somewhere that I don't know "proper ways of reloading ipfw
 over network"?
 If one like to show of, bug report board isn't a good place to do that.
 
 > 2. Nice catch. 
 It isn't a catch, it's a report about bugs.
 
 > However, that's only one of reasons why it is
 > very bad habit to have "./" in PATH.
 
 It is a perfectly legal operation that shouldn't cause an error on the OS level.
 If one can't use a hummer and broke his finger because of that - it isn't mean
 that hummer is a bad tool.
 
 > 3. Please use "diff -u" to make unified diffs,
 > they are much easier to read.
 
 I'm agree with you on that but I used official advice
 http://www.freebsd.org/doc/en/articles/contributing/contrib-how.html
 that says:
 "The preferred diff(1) format for submitting patches is the unified 
 output format generated by diff -u. 
 However, for patches that substantially change a region of code, 
 a context output format diff generated by diff -c may be more readable
 and thus preferable."
 
 Unified patch attached.
 
 --========GMX20051292702401607924
 Content-Type: application/octet-stream; charset="utf-8"; name="ipfw.patch2.txt"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="ipfw.patch2.txt"
 Content-Description: Attachment: ipfw.patch2.txt
 
 LS0tIGlwZncub3JpZwkyMDEwLTA3LTMxIDE4OjUyOjU0LjAwMDAwMDAwMCAtMDQwMAorKysgaXBm
 dwkyMDEwLTEyLTE3IDEwOjAyOjU0LjAwMDAwMDAwMCAtMDUwMApAQCAtMzksNyArMzksMTggQEAK
 IAogCV9maXJld2FsbF90eXBlPSQxCiAKKwkjIGNoZWNrIGlmIGZpcmV3YWxsIGFscmVhZHkgcnVu
 bmluZyB0byBwcmV2ZW50IHN1YnNlcXVlbnQgc3RhcnQgY2FsbHMKKwkjCisJWyAkKCAke1NZU0NU
 TF9OfSBuZXQuaW5ldC5pcC5mdy5lbmFibGUgKSAtbmUgMCBdICYmIHsKKwkJd2FybiAnRmlyZXdh
 bGwgaXMgYWxyZWFkeSBydW5uaW5nLic7CisJCV9pcGZ3X3J1bm5pbmdfc3RhdHVzPTE7CisJCXJl
 dHVybiAxOworCX0gfHwgeworCQlfaXBmd19ydW5uaW5nX3N0YXR1cz0wOworCX0KKwogCSMgc2V0
 IHRoZSBmaXJld2FsbCBydWxlcyBzY3JpcHQgaWYgbm9uZSB3YXMgc3BlY2lmaWVkCisJIwogCVsg
 LXogIiR7ZmlyZXdhbGxfc2NyaXB0fSIgXSAmJiBmaXJld2FsbF9zY3JpcHQ9L2V0Yy9yYy5maXJl
 d2FsbAogCiAJaWYgWyAtciAiJHtmaXJld2FsbF9zY3JpcHR9IiBdOyB0aGVuCkBAIC01NSw3ICs2
 Niw3IEBACiAJIwogCWlmIGNoZWNreWVzbm8gZmlyZXdhbGxfbG9nZ2luZzsgdGhlbgogCQllY2hv
 ICdGaXJld2FsbCBsb2dnaW5nIGVuYWJsZWQuJwotCQlzeXNjdGwgbmV0LmluZXQuaXAuZncudmVy
 Ym9zZT0xID4vZGV2L251bGwKKwkJJHtTWVNDVExfV30gbmV0LmluZXQuaXAuZncudmVyYm9zZT0x
 ID4vZGV2L251bGwKIAlmaQogfQogCkBAIC02MywxMCArNzQsMTYgQEAKIHsKIAlsb2NhbAlfY29z
 Y3JpcHQKIAorCSMgc3RvcCBwcm9jY2Vzc2luZyBpZiBmaXJld2FsbCBpcyBhbHJlYWR5IHJ1bm5p
 bmcKKwkjCisJWyAke19pcGZ3X3J1bm5pbmdfc3RhdHVzfSAtZXEgMSBdICYmIHsKKwkJcmV0dXJu
 IDE7CisJfQorCiAJIyBTdGFydCBmaXJld2FsbCBjb3NjcmlwdHMKIAkjCiAJZm9yIF9jb3Njcmlw
 dCBpbiAke2ZpcmV3YWxsX2Nvc2NyaXB0c30gOyBkbwotCQlpZiBbIC1mICIke19jb3NjcmlwdH0i
 IF07IHRoZW4KKwkJaWYgWyAtZiAiJHtfY29zY3JpcHR9IiAtYSAteCAiJHtfY29zY3JpcHR9IiBd
 OyB0aGVuCiAJCQkke19jb3NjcmlwdH0gcXVpZXRzdGFydAogCQlmaQogCWRvbmUKQEAgLTk4LDEz
 ICsxMTUsMTggQEAKIAkjIFN0b3AgZmlyZXdhbGwgY29zY3JpcHRzCiAJIwogCWZvciBfY29zY3Jp
 cHQgaW4gYHJldmVyc2VfbGlzdCAke2ZpcmV3YWxsX2Nvc2NyaXB0c31gIDsgZG8KLQkJaWYgWyAt
 ZiAiJHtfY29zY3JpcHR9IiBdOyB0aGVuCisJCWlmIFsgLWYgIiR7X2Nvc2NyaXB0fSIgLWEgLXgg
 IiR7X2Nvc2NyaXB0fSIgXTsgdGhlbgogCQkJJHtfY29zY3JpcHR9IHF1aWV0c3RvcAogCQlmaQog
 CWRvbmUKIH0KIAogbG9hZF9yY19jb25maWcgJG5hbWUKLWZpcmV3YWxsX2Nvc2NyaXB0cz0iL2V0
 Yy9yYy5kL25hdGQgJHtmaXJld2FsbF9jb3NjcmlwdHN9IgorCitpZiBjaGVja3llc25vIGZpcmV3
 YWxsX25hdF9lbmFibGU7IHRoZW4KKwlmaXJld2FsbF9jb3NjcmlwdHM9Ii9ldGMvcmMuZC9uYXRk
 ICR7ZmlyZXdhbGxfY29zY3JpcHRzfSIKK2VsaWYgY2hlY2t5ZXNubyBuYXRkX2VuYWJsZTsgdGhl
 bgorCWZpcmV3YWxsX2Nvc2NyaXB0cz0iL2V0Yy9yYy5kL25hdGQgJHtmaXJld2FsbF9jb3Njcmlw
 dHN9IgorZmkKIAogcnVuX3JjX2NvbW1hbmQgJCoK
 --========GMX20051292702401607924--