RFC: Firewalld provider model

Radek Novacek rnovacek at redhat.com
Fri Sep 19 10:58:23 UTC 2014


Thanks for your remarks, my comments are inline. I'll send out updated version 
of the model soon.

On Wed 27 of Aug 2014 15:59:18 Jan Safranek wrote:

> Hello,
> 
> thanks for the proposal. Here come my remarks:
> 
> 1) Association classes are done differently in UML. In plantuml:
> 
> class CIM_ComputerSystem
> class LMI_FirewallConfigurationService
> class LMI_HostedService
> (CIM_ComputerSystem, LMI_FirewallConfigurationService) .. LMI_HostedService
> 
> http://codeuml.com/?635447417355422516
> 
> Now it's hard to see what's a real class and what's an association.

Fixed, although the schema is still too crowded, so I changed associations 
without any additional properties to just:

CIM_ComputerSystem .. LMI_FirewallConfigurationService : LMI_HostedService

(just a line with association class name), it looks simpler.

> 2) I don't like LMI_HostedFirewalldService association.
> CIM_HostedService connects ComputerSystem with services, that manage
> something and the name of LMI_HostedFirewalldService implies it inherits
> it. In addition, the rest of the rules are not connected to
> ComputerSystem either,

I've renamed the LMI_HostedFirewalldService class to 
LMI_FirewalldServiceOnSystem (I can't figure out better name, suggestions?).

Only LMI_FirewalldService and LMI_FirewalldICMPType instances are connected to 
ComputerSystem because there are persistent and shared between zones in the 
firewalld API.

> 3) I miss some example with one service in multiple zones - will there
> be one LMI_FirewalldService instance for both zones or will each zone
> have separate instance?

The instance will be shared. Firewalld has permanent list of services that are 
shared between zones. I'll state that in explicitly in the 
LMI_FirewalldService description.

> In the first case, how do you disable this service in one zone, leaving
> it in the other one? LMI_FirewalldService.DeleteInstance() will remove
> the instance, not the association to zone.

My idea was to delete LMI_FirewalldZoneComponent instance for disabling 
service in one zone only.

> In the second case, what if I add a port to only one instance? Thy are
> independent instances, so from CIM point of view it should be possible.
> IMO firewalld does not allow this.
> 
> 
> 3) Manipulation with the rules is not atomic. e.g. in "3.2.4 Forward
> port", one creates a new rule with zone.AddForwardPort(). After the
> method call:
> - is the incomplete rule added to firewall?
> - where does it send packets to?
> - what if the client crashes before it adds a destination address/port?
> - how to find these incomplete rules?
> 
> The same applies to "3.2.3 Opening a range of ports" - by calling
> zone.AddPort() you must add one port to the firewall. By rule.push() you
> must remove it (!) and add a new rule with a port range. This looks messy.
> 
> I think we should only insert complete rules to the firewall, without
> intermediate objects.

Right, I've been thinking about this option too, but I rejected it that time 
because the number of parameters of the call (e.g. AddForwardPort) increases a 
lot. To simplify the model at least a little bit, I'll try to merge the 
Port/PortRangeHigh into one parameter Port (string type) that will be either 
number as a string or dash separated port range: '1234-2345'. That should also 
reduce the number of params.

> 4) What is the purpose of LMI_FirewalldRuleComponent association? Why
> can LMI_FirewalldPort have a subcomponents, e.g. a service or ICMPType?
> Shouldn't LMI_FirewalldRuleComponent associate only rules to
> LMI_FirewalldService?

In general, Rule can consist of some sub-rules - for example Service can have 
Ports, or Rich Rule can consist of some more rules. 

I'll break it to two associations - LMI_FirewalldServicePort and 
LMI_FirewalldRichRuleComponent. That should make it more clear.

> 5) How to add rules to a service? There is
> LMI_FirewalldService.AddPort(), which is pretty clear, but what does
> LMI_FirewalldRule.AddRuleComponent() do? It must get an already existing
> rule, associated to a zone or another LMI_FirewalldRule. Will the rule
> _move_ to FirewalldRule and all previous associations will be removed,
> or will it create a copy?

This is connected to the point 4), AddRuleComponent should create 
LMI_FirewalldRuleComponent - mostly in the Rich Rules. I'll replace it with 
Add*() methods (like AddPort, AddService, etc.).

Thanks for you comments.

Radek Novacek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20140919/2f35bf67/attachment-0001.html>


More information about the openlmi-devel mailing list