Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 568528
Summary: | firewall --disabled still produces a blocking /etc/sysconfig/iptables | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Orion Poplawski <orion> | ||||
Component: | anaconda | Assignee: | Martin Sivák <msivak> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 13 | CC: | awilliam, dcantrell, jlaska, jonathan, kparal, tony.molloy, twoerner, vanmeeuwen+fedora, wwoods | ||||
Target Milestone: | --- | Keywords: | CommonBugs, Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | https://fedoraproject.org/wiki/Common_F13_bugs#firewall-blocking-ssh | ||||||
Fixed In Version: | anaconda-13.40-1.fc13 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-05-05 21:42:29 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 583986 | ||||||
Bug Blocks: | 507681 | ||||||
Attachments: |
|
Can you see which package is creating /etc/sysconfig/iptables? From the top line in iptables, I assume system-config-firewall. Does updates=http://clumens.fedorapeople.org/568528.img fix this? Nope. No longer have /etc/sysconfig/system-config-firewall.old, and /etc/sysconfig/system-config-firewall is the "anaconda" version, but I still have the same /etc/sysconfig/iptables*. Thanks for testing. That's a minor improvement, but I'll give it another look and see what's still missing. Ah I see it now. I can fix the duplication which is obviously wrong. However there's a secondary problem here that needs to be addressed in lokkit. anaconda runs lokkit twice: once to set up the selinux stuff and once to set up the firewall stuff. This is because that information is contained it two separate objects. However on the run that just does selinux, we run lokkit with --quiet --nostart --selinux=enforcing. Since there's no --disabled parameter this time, it generates an iptables config. I suppose we could just add --disabled the first time through running lokkit in case the user later does not want a firewall. However that does kind of seem like a hack. Is there any reason lokkit can simply not do anything regarding iptables configuration if dealing with --selinux=? It seems like lokkit can run in a couple different modes here. Chris: The problem is in the code of anaconda (firewall.py): try: if not os.path.exists("%s/etc/sysconfig/iptables" %(instPath,)): iutil.execWithRedirect("/usr/sbin/lokkit", args, root=instPath, stdout="/dev/null", stderr="/dev/null") else: log.error("would have run %s", args) You are writing /etc/sysconfig/system-config-firewall by hand and lokkit is not used. The first lokkit call to alter selinux configuration is creating a fresh configuration, because there is none. The second lokkit call to disable the firewall never occurs. I admit that the selinux call might not create a firewall configuration, but I have seen scripts where lokkit is used to alter selinux and the firewall in one call. Another solution is needed to fix #502479. It might be sufficient to remove the "-f" flag from the lokkit call, this will not kill custom configurations. But on the other hand: Maybe is creating a fresh configuration in a live installer not wanted at all? I do not know. anaconda-13.35-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.35-1.fc13 I still have the problem with 13.35. anaconda-13.35-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. This is NOT fixed in 13.35 or 13.36. This is getting pretty annoying. Anything I can do to help fix? I talked to Thomas and he will help us by adding --nofw (or similar) option to lokkit, so we would be writing the firewall config file only once. It should be a pretty trivial fix afterwards. As a further note, this bug causes default F13 Beta installs to have the SSH port closed. Users can manually open the ssh port using system-config-firewall: 1) Start system-config-firewall (System->Administration->Firewall) 2) When prompted, enter the root password 3) Disable and re-enable the 'SSH' service 4) Click 'Apply' Discussed at today's blocker review meeting. We agreed this technically doesn't infringe any existing release criterion, but we believe such an issue ought to block the release, so we've drafted a new criterion: "With the correct install configuration, it should be possible to make an installed system immediately remotely accessible (you should be able to install with a secure remote access service active and unblocked by firewall-type mechanisms)" and we'll accept this as a blocker provisionally, on the basis that we'll likely add that to the release criteria. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers 04/23 blocker meeting update: this is waiting on 583986. we will poke that bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Please have a look at #583986 - the update package is in testing. This bug was discussed at the 2010/04/30 blocker review meeting. We agreed that it remains a blocker, and noted that a system-config-firewall package with the required change is in updates-testing with +3 karma. So we think this is back with anaconda team to provide a patch, based on the updated s-c-f. Please try as hard as possible to have the changes ready for Tuesday 2010/05/04, when the Fedora 13 RC stage will be starting up. Thank you. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers No patch should be needed. It has to be tested though. *** Bug 586685 has been marked as a duplicate of this bug. *** Setting to ON_QA, then - QA folks, we need to test this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers I still see the problem with the install images in today's development/13 directory w/ anaconda 13.39 and s-c-f 1.2.25-1.fc13. program log shows that it runs: /usr/sbin/lokkit --quiet --nostart --selinux=enforcing Note that the iptables init script is set to automatically start. Please use "/usr/sbin/lokkit --selinux=enforcing" without quiet and nostart option for selinux only configuration. Thomas, I take it that advice is for the anaconda team? hence, assigning back to them. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Update from msivak ... 15:11:00 msivak_: jlaska: is it the one with lokkit? 15:11:18 msivak_: jlaska: I commited patch this afternoon so only a build Committed to f13-branch in anaconda. For details on the patch, see http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=273ac3b9930bc6ad6ac1a52a9c0341d8a801fa45 Moving to MODIFIED is the fix in the updates.img we have available for test? http://people.fedoraproject.org/~jwrdegoede/f13-updates.img (In reply to comment #26) > is the fix in the updates.img we have available for test? > > http://people.fedoraproject.org/~jwrdegoede/f13-updates.img Dunno, but I just built http://jlaska.fedorapeople.org/updates-568528.img which contains everything in anaconda f13-branch since anaconda-13.39-1 anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13 anaconda-13.40-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update anaconda'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13 (In reply to comment #27) > Dunno, but I just built http://jlaska.fedorapeople.org/updates-568528.img > > which contains everything in anaconda f13-branch since anaconda-13.39-1 This does not fix the issue for me. I performed standard DVD install, "firewall --service=ssh" is in the kickstart. Still I can't connect with ssh unless I stop iptables. "service iptables status" reports: Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination I did a completely stock install with the updates.img to see what that would give (as I understand the various reports, it ought to allow ssh access). It doesn't. It gives exactly the same configuration as Kamil posted. Agreed that this doesn't appear fixed. Please enable the Fedora 13 repo, it contains system-config-firewall-1.2.25-1, which is also needed. I tested again, using TC1 with Hans' updates.img from yesterday - http://people.fedoraproject.org/~jwrdegoede/f13-updates.img . I did a minimal install, and enabled the F13 and F13 test-updates repos. It still doesn't work right; the .ks includes firewall --service=ssh but the generated iptables config is still wrong. anaconda.log shows: anaconda.log:15:40:45,187 ERROR anaconda: would have run ['--quiet', '--nostart', '-f', '--service=ssh'] maybe hans' updates.img doesn't include the fix somehow? Or is this type of install hitting a different path? I know the updates.img itself did work, because I didn't see the 'pre-release warning' screen at the start of install; if you just use plain TC1, you do see that screen. I have created an updates.img file containing only security.py from anaconda GIT. Using this on top of the beta tree altogether with enabling the Fedora 13 repo makes it working for me. I installed a minimal system and the ssh port was open in the firewall in the end. okay, we worked out that none of the available updates.img files actually included the fix. so with a new version of hans' updates.img (same URL), it now works: the same test as above gives an iptables config with the ssh port open, as is supposed to be the case. We can consider this fixed when an image with the fixed anaconda is available. just checked; the released anaconda 13.40-1 does indeed include this fix. We should now be able to confirm that this bug is fixed using the images here: http://alt.fedoraproject.org/pub/alt/stage/13.0505/Fedora/i386/os/images/ if we have not yet confirmed the fix, can anyone able to reproduce this bug please test with one of those images and check that the bug is fixed? Thanks. Confirmed that it works with the new anaconda. I get ssh enabled once again. Works w/ Hans' updates.img for me. No /etc/sysconfig/iptables with "firewall --disabled". Thanks. Let's close this, then. anaconda-13.40-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 396405 [details] anaconda.log Description of problem: kickstart install with "firewall --disabled", results in an active firewall with the following /etc/sysconfig files: iptables: # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT iptables-config: # Load additional iptables modules (nat helpers) # Default: -none- # Space separated list of nat helpers (e.g. 'ip_nat_ftp ip_nat_irc'), which # are loaded after the firewall rules are applied. Options for the helpers are # stored in /etc/modprobe.conf. IPTABLES_MODULES="" # Unload modules on restart and stop # Value: yes|no, default: yes # This option has to be 'yes' to get to a sane state for a firewall # restart or stop. Only set to 'no' if there are problems unloading netfilter # modules. IPTABLES_MODULES_UNLOAD="yes" # Save current firewall rules on stop. # Value: yes|no, default: no # Saves all firewall rules to /etc/sysconfig/iptables if firewall gets stopped # (e.g. on system shutdown). IPTABLES_SAVE_ON_STOP="no" # Save current firewall rules on restart. # Value: yes|no, default: no # Saves all firewall rules to /etc/sysconfig/iptables if firewall gets # restarted. IPTABLES_SAVE_ON_RESTART="no" # Save (and restore) rule and chain counter. # Value: yes|no, default: no # Save counters for rules and chains to /etc/sysconfig/iptables if # 'service iptables save' is called or on stop or restart if SAVE_ON_STOP or # SAVE_ON_RESTART is enabled. IPTABLES_SAVE_COUNTER="no" # Numeric status output # Value: yes|no, default: yes # Print IP addresses and port numbers in numeric format in the status output. IPTABLES_STATUS_NUMERIC="yes" # Verbose status output # Value: yes|no, default: yes # Print info about the number of packets and bytes plus the "input-" and # "outputdevice" in the status output. IPTABLES_STATUS_VERBOSE="no" # Status output with numbered lines # Value: yes|no, default: yes # Print a counter/number for every rule in the status output. IPTABLES_STATUS_LINENUMBERS="yes" system-config-firewall: # Configuration file for system-config-firewall --disabled system-config-firewall.old: # system-config-firewall config written out by anaconda --disabled Version-Release number of selected component (if applicable): 13.31