Tony Nguyen wrote:
> 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.
>
Sounds good.
Scott
