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