Bug 145841

Summary: YaST shows "Firewall is disabled" even when it is running
Product: [openSUSE] SUSE Linux 10.1 Reporter: Johannes Meixner <jsmeix>
Component: YaST2Assignee: Lukas Ocilka <locilka>
Status: RESOLVED INVALID QA Contact: Edith Parzefall <eparzefall>
Severity: Major    
Priority: P5 - None CC: fs, scott
Version: Beta 1   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Johannes Meixner 2006-01-26 14:26:35 UTC
How to reproduce:

SuSEfirewall2 is not "insserverd":
caps:~ # find /etc/init.d/ | grep -i fire
/etc/init.d/SuSEfirewall2_init
/etc/init.d/SuSEfirewall2_setup

but it is running:
caps:~ # rcSuSEfirewall2 start
caps:~ # rcSuSEfirewall2 status
Checking the status of SuSEfirewall2                          running

Now start for example the YaST printer module:
[Other] -> "CUPS Exper settings"
[Next]
and you see that "Firewall is disabled".

As far as I know the YaST printer module uses CWMFirewallInterfaces
(or somthing like this) so that I assume the bug is there.
Comment 1 Johannes Meixner 2006-01-26 14:28:20 UTC
The bug was initially shown by Frank Sundermeyer to me.
Added 
Comment 2 Johannes Meixner 2006-01-26 14:35:16 UTC
The opposite is also wrong:

When the SuSEfirewall2 is "insserverd"
caps:~ # find /etc/init.d/ | grep -i fire
/etc/init.d/boot.d/S08SuSEfirewall2_init
/etc/init.d/boot.d/K14SuSEfirewall2_init
/etc/init.d/rc3.d/S21SuSEfirewall2_setup
/etc/init.d/rc3.d/K01SuSEfirewall2_setup
/etc/init.d/rc4.d/S21SuSEfirewall2_setup
/etc/init.d/rc4.d/K01SuSEfirewall2_setup
/etc/init.d/rc5.d/S21SuSEfirewall2_setup
/etc/init.d/rc5.d/K01SuSEfirewall2_setup
/etc/init.d/SuSEfirewall2_init
/etc/init.d/SuSEfirewall2_setup

but it is currently not running:
caps:~ # rcSuSEfirewall2 stop
caps:~ # rcSuSEfirewall2 status
Checking the status of SuSEfirewall2                          unused

then in the YaST printer module shows (at the same screen as above)
for example "Firewall port is closed" which is wrong because
all ports are actually open for all interfaces in all network zones
when no Firewall is running at all.

For me this wrong information looks like a major bug because
the user thinks he is protected but in fact he is totally unprotected.
Comment 3 Lukas Ocilka 2006-01-26 15:08:27 UTC
CWMFirewall interface can handle only two states: Enabled / Disabled. When the firewall is not enabled, but running, CWMFirewall consider the SuSEfirewall2 disabled because, it fact, it IS disabled.

If user has running firewall but it is disabled in the init scripts, it must have been started manually and that user has to set it up aslo manually (or using yast2-firewall)

Summarization:
Firewall can be: Running / Not Running
Firewall can be: Enabled / Disabled

If user starts firewall manually, CWMFirewall takes hands off.
Comment 4 Johannes Meixner 2006-01-26 15:17:59 UTC
It seems to be not true that
"If user starts firewall manually, CWMFirewall takes hands off."

If it was true why is there still the Firewall stuff active
in the printer module when it is not "insserverd" but running?
In particular why is there a checkbox regarding Firewall settings
active when "CWMFirewall takes hands off"?

Is this a bug in the printer module?

Comment 5 Lukas Ocilka 2006-01-26 15:31:21 UTC
You probably don't understand me correctly.

Typical user enables the firewall and it just runs. Then it also offers to itself to be configured via CWMFirewallAnything. If user enables the firewall but then he stops it, Firewall is still considered to be enabled and vice versa.

If you want to play with the firewall, run `yast2 firewall`. In fact, this problem is here just because init scripts were broken in Beta1 and SuSEfirewall2_* scripts couldn't have been enabled unless used --force function.
Comment 6 Johannes Meixner 2006-01-26 15:41:22 UTC
Thanks for clarification.

By the way:
At least Frank also didn't understand the underlying logic ;-)
Comment 7 Lukas Ocilka 2006-02-01 22:49:16 UTC
*** Bug 146614 has been marked as a duplicate of this bug. ***
Comment 8 Lukas Ocilka 2006-07-11 10:52:50 UTC
*** Bug 191461 has been marked as a duplicate of this bug. ***