Scott Rotondo wrote: > Tony Nguyen wrote: >> Jeffrey Hutzelman wrote: >>> --On Thursday, August 28, 2008 01:16:18 PM -0700 Tony Nguyen >>> <Truong.Q.Nguyen at Sun.COM> wrote: >>> >>>> Scott Rotondo wrote: >>>>> It would be ideal if the way of expressing service rules made it >>>>> impossible to affect other services. I don't think the current syntax >>>>> for service rules provides that assurance (and it may not be feasible to >>>>> do so), but it would be great if it could. >>>>> >>>> Agree, that would be the ideal solution. At the moment, I don't see a >>>> way to analyze an arbitrary set of rules for a conflicting subset. >>> No, of course not; the possibilities offered by ipf are too varied and >>> complex to allow that. >>> >>> What I think Scott was proposing is that services not get to specify >>> arbitrary ipf rules, but instead get to specify rules in a much more >>> restrictive language, which is designed such that you _can_ analyze for >>> conflicts, or even better, such that conflicts cannot occur. > > Yes, that's exactly what I meant. > >> As I clarified in a different post and Dave in another, users do not >> specify *any* rules. User configures a service's policy (deny/accept and >> a list of network entities) which is translated to ipf rules based on >> service's static network information. > > I haven't read the spec carefully enough to conclude that these > deny/accept rules cannot affect other services, but that's the question > I was trying to raise. If you've done the analysis and convinced > yourself of that, I'm willing to take your word for it. > >> The only customized rules are those delivered by service developers for >> services which has more complex network communication. In these cases, >> the service developers are responsible for correct system functioning >> when their service is running. > > If we have to provide the ability for services to deliver customized > rules, can we make it easy for the system administrator to find and > examine all such rules? >
The current implementation has a common directory in which each service's generated rules are stored in its own rule file. Service instance fmri is used to generate filename. Services generating custom rules are required to generate rules into its own file in the common location. This mechanism makes relatively easy for system administrators to examine the rules. Thanks, tony
