On Tue, Oct 20, 2009 at 01:51:28PM -0400, Anurag S. Maskey wrote: > > > Michael Hunter wrote: >> On Tue, 20 Oct 2009 09:05:08 -0700 >> Renee Danson Sommerfeld <renee.sommerfeld at sun.com> wrote: >> >> >>> On Tue, Oct 20, 2009 at 11:02:19AM -0400, Anurag S. Maskey wrote: >>> >>>> Michael Hunter wrote: >>>> >>>>> Please look at /net/coupe.eng/builds/mph/nwam1_work/webrev for: >>>>> >>>>> >>> [...] >>> >>>> net-loc:599-603 Hate to add another complexity to the User >>>> location, but "ipfilter-config-file" is hacked to achieve two >>>> different things. Its commented in net-nwam:267-270. If >>>> firewall_config_default/policy property of ipfilter is set to >>>> "none", "allow", or "deny", ipfilter-config-file saves this value >>>> as /none, /allow, or /deny respectively (The / is necessary >>>> because the property expects an absolute path). If the policy >>>> property is "custom", then ipfilter-config-file has the path to >>>> file (just like the other *-config-file) properties. There is no >>>> need to append to the copy_user_files script if /none, /allow or >>>> /deny exist. >>>> >>> Hmm. This is a problem for the User location. If we claim that it >>> will activate your environment as it existed prior to upgrade, AND >>> it's a first-class Location, you need to be able to apply it at any >>> time. That means the profile needs to contain the value of the >>> policy property, and the Location script needs to be able to apply >>> that property value when activating the location. >>> >> >> So this is broken for any location other than Legacy, right? >> > No, it's broken for the User location (specifically, when /none, /allow > or /deny is used for the ipfilter-config-file property) because it came > from the Legacy location (which isn't activated). The other locations > take the path to the config file and uses the "custom" firewall policy > with the file.
Right, this would be an unadvertised "feature." Currently, the only type of ipfilter configuration we support is where the user provides a file, and we set the policy to "custom" and point ipf at the user- specified file(s). That all works. The problem is if the User location is intended to replicate the pre-nwam configuration to the extent that non-custom ipfilter policy actually continues to work. That's specific to the User location. This is the ipfilter can of worms I mentioned last week. If we want to fully support ipfilter-based firewall configuration, we need to: * add properties for the various firewall-related properties of the ipfilter service, including policy, exceptions, and open_ports * (the killer) figure out how to capture the per-service configuration rules; in the allow/deny policy cases, each relevant service has its own properties that the ipfilter method script munges through to construct the rule set. Capturing and applying that data on the fly is no small task, and is (in my opinion) more than we should take on right now. Even if we chose to leave the latter part up to the user to change as they see fit, adding the new properties to the GUI would be non-trivial extra work. This is why I recommended the more hacky approach. I don't *like* it, but it seems like the only feasible answer for right now. -renee > Recall how well the ipfilter config file for NoNet works. > > Anurag > >> >>> We *could* hack around not having an explicit policy property in the >>> User loc by simply saving things as they are in the Legacy loc, and >>> then when activating a location, checking for those special values >>> and setting the ipfilter service's policy property accordingly (instead >>> of always setting it to custom and copying over a file, which I believe >>> is what we do now). I think that's the least invasive approcah. >>> >>> Actually adding an ipfilter-policy property to the location is >>> appealing, and less hacky; but I think would require us to provide >>> more complete support for the ipfilter firewall config than we do >>> right now, and is too much to take on prior to integration. >>> >> >> I like the less hacky approach. >> >> >>> Thoughts? >>> >> >> I'd like to get this code pushed for RC4. Given it is currently broken for >> real locations I'd like to argue that a bug be filed for this issue and >> fixed for the next go around. >> >> webrev updated at /net/coupe.eng/builds/mph/nwam1_work/webrev (untested) >> >> Michael >> >> >>> -renee >>>
