FirewallEnums.hpp

1. Overview

The FirewallEnums.hpp header defines the FirewallType enumeration, which provides a centralized and strongly typed representation of supported firewall backends within BastionGuard.

This enumeration is used across detection, configuration, installation, and UI components to ensure consistent handling of firewall-related logic.

Functionally, this module provides:

  • A unified type system for firewall backend identification
  • Type-safe communication between firewall subsystems
  • Elimination of string-based firewall comparisons
  • Improved maintainability and refactoring safety
  • Centralized definition of supported firewall technologies

2. Dependencies and Includes

This header does not include any standard or third-party libraries. It is designed to be lightweight and dependency-free.

3. Enumeration Declaration and Scope

enum class FirewallType {
    NONE,
    FIREWALLD,
    UFW
};

The enumeration is declared as a scoped enum (enum class), providing strong type safety and preventing implicit conversions to integer values.

4. Enumeration Values

  • NONE – no supported firewall backend detected or configured
  • FIREWALLD – firewalld framework (commonly used on Fedora, RHEL, CentOS)
  • UFW – Uncomplicated Firewall (commonly used on Ubuntu and derivatives)

5. Usage Context

FirewallType is used throughout BastionGuard to represent firewall-related state in a consistent manner, including:

  • Environment detection (FirewallDetector::detectFirewall())
  • User selection (FirewallChoiceDialog)
  • Installation logic (FirewallInstaller)
  • Settings persistence
  • Firewall rule management subsystems

6. Internal State and Data Model

This header defines no runtime state. The enumeration is a compile-time construct used for type-safe control flow.

7. Integration Patterns

Typical usage patterns include:

FirewallType fw = FirewallDetector::detectFirewall();

if (fw == FirewallType::FIREWALLD) {
    // Configure firewalld
} else if (fw == FirewallType::UFW) {
    // Configure UFW
}

Scoped enumeration values must be qualified with the enumeration name, improving readability and reducing naming collisions.

8. Extensibility

New firewall backends can be added by extending this enumeration with additional values, followed by corresponding updates in detection and management components.

9. Auto-Update (Scheduled Refresh)

This module does not implement runtime behavior and does not require periodic refresh.

10. Settings Storage

Enumeration values are typically serialized to configuration files using string or numeric representations defined by higher-level modules.

11. Compatibility Considerations

  • ABI stability: changing enumeration ordering may affect binary compatibility when values are serialized numerically.
  • Backward compatibility: adding new values should preserve existing semantics.
  • Interoperability: external configuration formats should use symbolic names rather than raw integers.

12. Runtime and Security Considerations

  • Fail-safe defaults: FirewallType::NONE should be handled conservatively to avoid leaving systems unprotected.
  • Validation: persisted or user-supplied values must be validated before casting to FirewallType.
  • Defensive coding: switch statements should include default cases to handle unknown values.
Published on:
Last updated on: