Bugzilla – Bug 468426
yast2-firewall: inconsistent configuration data
Last modified: 2009-02-17 13:29:00 UTC
Jan-Christoph Bornschlegel reported this issue. In the YaST firewall module he had enabled the service "cups" for the external zone but the YaST printer module shows "Access and printer information from the external network zone is denied" which is in contradiction to the actual firewall settings. yast2-printer determines the firewall status regarding IPP (port 631 UDP and TCP) in Printer.ycp via ------------------------------------------------------------------- if( ! SuSEFirewall::HaveService( "631", "UDP", "INT" ) ) { firewall_config["browsing_from_int"] = false; firewall_config["ui_browsing_from_int"] = false; } if( ! SuSEFirewall::HaveService( "631", "TCP", "INT" ) ) { firewall_config["access_from_int"] = false; firewall_config["ui_access_from_int"] = false; } ... if( SuSEFirewall::HaveService( "631", "TCP", "EXT" ) || SuSEFirewall::HaveService( "631", "UDP", "EXT" ) ) { firewall_config["deny_from_ext"] = false; firewall_config["ui_deny_from_ext"] = false; } ------------------------------------------------------------------- In y2log there is ------------------------------------------------------------------- SuSEFirewall.ycp:2372 Firewall configuration has been read: $["FW_ALLOW_FW_BROADCAST_DMZ":"no", "FW_ALLOW_FW_BROADCAST_EXT":"no", "FW_ALLOW_FW_BROADCAST_INT":"no", "FW_CONFIGURATIONS_DMZ":"", "FW_CONFIGURATIONS_EXT":"cups dhcp-server sshd", "FW_CONFIGURATIONS_INT":"", "FW_DEV_DMZ":"", "FW_DEV_EXT":"any br0", "FW_DEV_INT":"", "FW_FORWARD_ALWAYS_INOUT_DEV":"", "FW_FORWARD_MASQ":"", "FW_IGNORE_FW_BROADCAST_DMZ":"no", "FW_IGNORE_FW_BROADCAST_EXT":"yes", "FW_IGNORE_FW_BROADCAST_INT":"no", "FW_IPSEC_TRUST":"no", "FW_LOAD_MODULES":"nf_conntrack_netbios_ns", "FW_LOG_ACCEPT_ALL":"no", "FW_LOG_ACCEPT_CRIT":"yes", "FW_LOG_DROP_ALL":"no", "FW_LOG_DROP_CRIT":"yes", "FW_MASQUERADE":"no", "FW_PROTECT_FROM_INT":"no", "FW_ROUTE":"no", "FW_SERVICES_ACCEPT_DMZ":"", "FW_SERVICES_ACCEPT_EXT":"", "FW_SERVICES_ACCEPT_INT":"", "FW_SERVICES_ACCEPT_RELATED_DMZ":"", "FW_SERVICES_ACCEPT_RELATED_EXT":"", "FW_SERVICES_ACCEPT_RELATED_INT":"", "FW_SERVICES_DMZ_IP":"", "FW_SERVICES_DMZ_RPC":"", "FW_SERVICES_DMZ_TCP":"", "FW_SERVICES_DMZ_UDP":"", "FW_SERVICES_EXT_IP":"", "FW_SERVICES_EXT_RPC":"", "FW_SERVICES_EXT_TCP":"ssh ", "FW_SERVICES_EXT_UDP":"", "FW_SERVICES_INT_IP":"", "FW_SERVICES_INT_RPC":"", "FW_SERVICES_INT_TCP":"", "FW_SERVICES_INT_UDP":"", "enable_firewall":true, "start_firewall":true]. ... Printer.ycp:1943 FirewallConfig read result: $["access_from_int":true, "browsing_from_int":true, "deny_from_ext":true, "firewall_active":true, "no_firewall_for_int":true, "suse_firewall_used":true, "ui_access_from_int":true, "ui_browsing_from_int":true, "ui_deny_from_ext":true] ------------------------------------------------------------------- This is wrong because on the one hand there is "FW_CONFIGURATIONS_EXT":"cups dhcp-server sshd", but on the other hand for yast2-printer it is "deny_from_ext":true, Something is wrong with the YCP code in yast2-printer which determines the firewall settings but this code had worked well at the time when I implemented it on my openSUSE 11.0 workstation.
SuSEfirewall newly uses services defined by packages. These services are defined by separate files in /etc/sysconfig/SuSEfirewall2.d/services directory. These services are different to the previous firewall settings because they add one another level of transparency. You don't check the ports anymore, you just check the availability of a service in configuration (of allowed services). See "FW_CONFIGURATIONS_EXT":"cups dhcp-server sshd", Your printer configuration checks the low level settings, what you need is the higher level of checking, for instance: * IsServiceSupportedInZone IsServiceSupportedInZone ("service:irc-server", "EXT") -> true * GetServicesInZones GetServicesInZones (["samba-server"]) -> $["samba-server":$["eth1":false]] See http://forgeftp.novell.com/yast/doc/SL11.1/modules/SuSEFirewall.html for more information. You are currently using this: SuSEFirewall::HaveService( "631", "UDP", "INT" ) SuSEFirewall::HaveService( "631", "TCP", "EXT" ) By the way, Miso uses an agent for tuning the configuration defined by service (that sysconfig file in /etc/sysconfig/SuSEfirewall2.d/services directory) for apache configuration. You can use the same approach for fine-tuning of the printer configuration.
I use what you told me some time ago how to implement it (it was when I implemented it for the YaST scanner module where it is perhaps now also wrong). I like incompatible changes! I provided the new YaST printer module via the openSUSE build service also for previous openSUSE versions. How should we ever provide stable and reliably working software for our customers when things change in incompatible ways? Because of limited time all I can do is to ignore previous openSUSE versions in the future.
Well, checking for port 631 on TCP and UDP still works, and you can still open and close the ports if you want. SuSEFirewall had some built-in services definitions which were removed in 11.1 because it was impossible to maintain them and impossible to configure a firewall properly this way. Yes, it's true this was incompatible change and I'm sorry for that but it was the only way how to do it. I remember posting several messages on yast-devel mailing-list about the planned changes and blogging, e.g. http://kobliha-suse.blogspot.com/2008/06/firewall-services-defined-by-packages.html
Many thanks for comment #5! I think I have now a much better understanding of what actually happened. But I need to experiment a bit with it before I change my code in yast2-printer and yast2-scanner. As far as it understand it currently (based on comment #5) this is actually no incompatible change (because the old stuf still works) but is is a new and different (alternative) way to set it up. The only issuze was that up to now I was not aware of the stuff in https://bugzilla.novell.com/show_bug.cgi?id=247746 in particular not aware that this means that my old code (which does intentionally a low-level port/protocol/zone check to be independent of any higher-level stuff) does no longer work. As far as it understand it currently I can keep the old checks via SuSEFirewall::HaveService(...) but I must add new checks via SuSEFirewall::IsServiceSupportedInZone("service:cups", "EXT") to test also for the new and different way. According to http://forgeftp.novell.com/yast/doc/SL11.0/modules/SuSEFirewall.html and http://forgeftp.novell.com/yast/doc/SL10.3/modules/SuSEFirewall.html#IsServiceSupportedInZone SuSEFirewall::IsServiceSupportedInZone works even for openSUSE 11.0 and openSUSE 10.3 so that there is sufficient backward compatibility even for previous openSUSE versions which makes me really happy! What I need to test is what happens if there are several sysconfig file like /etc/sysconfig/SuSEfirewall2.d/services/cups-browsing (which has only UDP="ipp" set) and /etc/sysconfig/SuSEfirewall2.d/services/cups-share-printers (which has only TCP="ipp" set). I guess that in this case I would have to test for SuSEFirewall::IsServiceSupportedInZone("service:cups-browsing", "EXT") and SuSEFirewall::IsServiceSupportedInZone("service:cups-share-printers", "EXT") which makes it unpredictable for me because my code then depends on file names in /etc/sysconfig/SuSEfirewall2.d/services/ (or on the "## Name:" entries in those files) which can both change without any notification to me and/or which can be changed manually by an experienced user but my YaST modules cannot adapt automatically to such changes. Therefore I would very much prefer if only a low-level port/protocol/zone check would be sufficient to test if a particular port is open for a particular protocol in a particular zone regardless how this was set up on a higher level. Because the /etc/sysconfig/SuSEfirewall2.d/services/ files contain port and protocol information and during setup the user defines the zone, the YaST firewall module should maintain the low-level port/protocol/zone information so that the low-level port/protocol/zone check still works correctly regardless of the way how it was set up. I assume YaST firewall module could during startup read /etc/sysconfig/SuSEfirewall2 and the /etc/sysconfig/SuSEfirewall2.d/services/ files to generate the low-level port/protocol/zone information. In particular on the user interface there should be no difference if the user has allowed "cups" for EXT or if he allowed port 631 for TCP and UDP for EXT. I tested what happens when I allow "cups" for EXT and allow port 631 for TCP and UDP for EXT in the YaST firewall module. I get then in y2log (shortened): ------------------------------------------------------------ SuSEFirewall.ycp:2372 Firewall configuration has been read: ... "FW_CONFIGURATIONS_EXT":"cups sshd", ... "FW_SERVICES_EXT_TCP":"631 ssh", "FW_SERVICES_EXT_UDP":"631", ------------------------------------------------------------ and the YaST printer module shows the right state. While the values of the Firewall configuration are now consistent, there is confusion on the user interface because when I run the YaST firewall module a second time, there are no longer any entries in the "Advanced" popup for port 631 for TCP and UDP for EXT but a second run of the YaST printer module shows still in y2log the same ------------------------------------------------------------ SuSEFirewall.ycp:2372 Firewall configuration has been read: ... "FW_CONFIGURATIONS_EXT":"cups sshd", ... "FW_SERVICES_EXT_TCP":"631 ssh", "FW_SERVICES_EXT_UDP":"631", ------------------------------------------------------------ and the YaST printer module shows the right state. Now I run YaST firewall module a third time and delete "cups" for EXT (but do nothing else) and re-run the YaST printer module it results in y2log ------------------------------------------------------------ SuSEFirewall.ycp:2372 Firewall configuration has been read: ... "FW_CONFIGURATIONS_EXT":"sshd", ... "FW_SERVICES_EXT_TCP":"631 ssh", "FW_SERVICES_EXT_UDP":"631", ------------------------------------------------------------ and the YaST printer module shows the right state. Meanwhile I think the main bug is in the YaST firewall module because it does not keep consistency. As far as I can see to keep consistency, the YaST firewall module must maintain the low-level port/protocol/zone information. But when it does this, a positive side-effect is that it also provides consistency when other YaST modules do intentionally a low-level port/protocol/zone check via SuSEFirewall::HaveService(...) to get intentionally a result which is independent of the way how the user may have set it up. Therefore I reassign it now to you. Nevertheless to be on the safe side I will add new checks in yast2-printer and yast2-scanner via SuSEFirewall::IsServiceSupportedInZone("service:cups", "EXT") to test also for the new and different way.
The SuSEFirewall YCP module might read all the SuSEfirewall2 sysconfig files to provide SuSEFirewall::HaveService() result containing this pieces of information, nevertheless it will never be possible to set the content of those sysconfig files by disabling "TCP" port "631" there.
In yast2-printer version 2.18.5 (i.e. for openSUSE 11.2) I removed the firewall settings which I added in version 2.17.29 because it is not possible to implement it so that it works correct and future-proof because it has become unpredictable for me (see comment #6). Additionally a generic solution can also not be implemented because it is not possible to test on the local host if remote access via port 631 TCP/UDP would be allowed (there is no replacement for "ipchains --check"). Finally any kind of firewall check would not make much sense because the user could first set up printing with firewall settings which allow printing so that the check would have a positive result but later he may change the firewall so that printing does no longer work. Therefore in the end all I could do was to add at least generic static notification texts regarding firewall directly in the dialogs and I added also explanatory help texts regarding firewall so that the users are at least informed what to do manually regarding firewall.