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