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. 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 >>
