Date: Sat, 18 Dec 2010 20:00:23 GMT From: "Alexander Verbod" <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com> To: freebsd-ipfw@FreeBSD.org Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Message-ID: <201012182000.oBIK0N6Q022100@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/153252; it has been noted by GNATS.
From: "Alexander Verbod" <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>
To: bug-followup@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@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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012182000.oBIK0N6Q022100>