On 3/5/11 9:26 AM, Evi1M4chine wrote: > >> If you are so attached to your shell variable that you can't bear to >> part with it, replace: > Why that hatred against variables? Maybe you did not mean it like that, > but you sound like you think I’m stupid for doing it like this. Without > saying why. I still assume you agree that variables are a good idea for > clean and structured code (including configuration files). But man, why > the passive aggression? If you think I’m wrong: I love to learn > something. :)
I agree that the variable is a good thing. > >> BEGIN SHELL >> for type in $GOOD_ICMP_TYPES; do >> echo "ACCEPT z1 z2 icmp $type" >> done >> END SHELL >> >> That's basically what Shorewall-shell did for you. > *g* You call that horrible code structure? If a simple loop would cause > chaos of horror-proportions, the code wouldn’t be very good to begin > with, right? ;) > I doubt this is the case, because there must already be a loop for port > lists, which could do this too (acting as if ICMP types just were ports) > elegantly. Please refer to my follow-on post. The problem with doing it that way is that the contents of a single column must drive the entire processing of the rule. There are PORT columns in many of Shorewall's configuration files so if I implemented the code that way in the compiler, there would have to be such a loop in the processing of every file with such a column. > In fact I would have implemented it this way. You (and I) might have indeed done it that way if your product only had one file with PORT columns. > >> It is really very obvious -- use multiple rules with one type per rule. > That is the first thought about the options left, that I had. > But I refused to call it an option, as it is so deeply wrong. As a > programmer, I learned, that if you have to do something over and over > again, you automate it. That’s what this machine is for, after all. :) Again, we are in violent agreement. > >> BUT.... there is really no reason the have explicit rules for 'Good' >> ICMPs; Shorewall automatically allows necessary ICMP types through, even >> if they are against the relevant policy. > > I’m sorry but if Shorewall blocks even standard ping *in a high-security > vpn inside my own trusted network*, that’s a bit overkill, isn’t it. ;) > I understand that on an open net, it is a good idea, and therefore a > smart default to block them. But you can’t say that there is no reason > at all for ever having a list of good ICMP types. Remember: If you > assume your users are idiots, then idiots you will get. ;) So let us > decide, and save yourself the work too. :) ICMP echo-request is a single type; mentioning it in the context of a discussion of 'good lists' is a bit if a stretch, don't you think? > (Also, using some other ping like over TCP, until that one gets the same > negative connotation as ICMP ping [for no valid reason IMHO], and gets > blocked too, is really as pointless as using “colored”, until that one > gets the same negative connotation that “black” somehow got, and becomes > a taboo too. As someone can just as much check if a host is online with > ICMP ping disabled, it becomes mere window-dressing. :) Well, a single 'ACCEPT all all icmp 8' rule changes the default, right? > > Well, of course you can do what you want with your own software and > time. So I guess if I will implement a nice and elegant patch for it > myself, and add it to my distro’s package. :) I believe that the patch included in my follow-on post is quite elegant :-) Feel free to add it to your distro's package in advance of the release of 4.4.19. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
