Is it possible to delete the default zones in Firewalld, and if not, why? - eviltoast

If you try to remove one of the predefined zones from Firewalld, e.g. public, you encounter the following error:

Error: BUILTIN_ZONE: 'public' is built-in zone

I don’t like that Firewalld is bloated with all of these built in zones that I will never use. I want to get rid of them, but, from what I’ve been able to find, it appears non-trivial to do so.

EDIT (2024-01-27T01:55Z):

I came across this GitHub issue. So it appears that this is a known “issue”, and it could potentially be changed in the future, albeit probably far in the future. It is a very strange initial design choice, though, in my opinion.

  • BCsven@lemmy.ca
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    10 months ago

    The zones are there so you can set your ports/services as needed for home, work, public wiffi etc. the idea is you leave your ports alone and just swap adapter to the zone you are working in. Network Manager has a quick toggle on wifi to do this from connection settings. So at home your laptop has ssh, smb open etc, when you connect to starbucks wifi you set wifi to public. The other part of zones is each as a fallback default you can specify. So if a port or service traffic doean’t match your home zone you can have if failover to default, in my case default is public. if that doean’t match either it can failover to “drop” or “block” etc. they have a heirachy.

    if you are just dealing with cli it can be intimidating. You can try OpenSUSE in a VM and use the Yast Firewall Gui tool to play around with adapter, default, zones, services and ports and get familiar with the idea behind it.

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      10 months ago

      I believe you may have misinterpereted my post. I wasn’t asking why zones exist, I was asking specifically why one cannot delete the default zones in Firewalld.

      • BCsven@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules. Maybe you know that already. If you have a static machine at work mayne you don’t need home zone, but it is not causing “bloat”. You would also still need drop, block and so on. My thought is if you think firewalld is bloat, just use iptables directly.

        • Kalcifer@sh.itjust.worksOP
          link
          fedilink
          arrow-up
          1
          arrow-down
          2
          ·
          edit-2
          10 months ago

          I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules.

          Yes, I am aware of that. Just allow the user to specify the zones though. Why force the default ones?

          but it is not causing “bloat”.

          It is if it’s saving alternative configuration that will never be used.

          just use iptables directly.

          This is essentially what I ended up doing.

          • BCsven@lemmy.ca
            link
            fedilink
            arrow-up
            2
            ·
            10 months ago

            It makes sense for them to include the Reject, drop, type for obvious reasons, the others seem like they asked “what will be the most common use cases for networks?” so they threw them in as work, home, public and trusted, external, dns , etc so that somebody starting out doesn’t have to create zones from scratch. I doubt having one extra zone takes up very much in the way of kb of space. compared to how much junk I have in my downloads folder that i should triage. What would be nice though would be a rename function, because we may have different Work rules depending on which workplace you are at that day with a system.