Bug 568528 - firewall --disabled still produces a blocking /etc/sysconfig/iptables
firewall --disabled still produces a blocking /etc/sysconfig/iptables
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Martin Sivák
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
: 586685 (view as bug list)
Depends On: 583986
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2010-02-25 17:09 EST by Orion Poplawski
Modified: 2013-01-10 00:45 EST (History)
9 users (show)

See Also:
Fixed In Version: anaconda-13.40-1.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-05 17:42:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (39.26 KB, text/plain)
2010-02-25 17:09 EST, Orion Poplawski
no flags Details

  None (edit)
Description Orion Poplawski 2010-02-25 17:09:15 EST
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
Comment 1 Chris Lumens 2010-02-25 17:27:46 EST
Can you see which package is creating /etc/sysconfig/iptables?
Comment 2 Orion Poplawski 2010-02-25 17:30:23 EST
From the top line in iptables, I assume system-config-firewall.
Comment 3 Chris Lumens 2010-02-26 13:38:05 EST
Does updates=http://clumens.fedorapeople.org/568528.img fix this?
Comment 4 Orion Poplawski 2010-02-26 16:07:07 EST
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*.
Comment 5 Chris Lumens 2010-02-26 16:08:46 EST
Thanks for testing.  That's a minor improvement, but I'll give it another look and see what's still missing.
Comment 6 Chris Lumens 2010-03-02 13:19:30 EST
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.
Comment 7 Thomas Woerner 2010-03-12 10:47:39 EST
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.
Comment 8 Fedora Update System 2010-03-18 13:22:49 EDT
anaconda-13.35-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/anaconda-13.35-1.fc13
Comment 9 Orion Poplawski 2010-03-18 13:40:26 EDT
I still have the problem with 13.35.
Comment 10 Fedora Update System 2010-03-22 22:26:20 EDT
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.
Comment 11 Orion Poplawski 2010-03-23 17:05:16 EDT
This is NOT fixed in 13.35 or 13.36.
Comment 12 Orion Poplawski 2010-04-09 18:38:17 EDT
This is getting pretty annoying.  Anything I can do to help fix?
Comment 13 Martin Sivák 2010-04-12 04:25:28 EDT
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.
Comment 14 Will Woods 2010-04-12 16:00:24 EDT
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'
Comment 15 Adam Williamson 2010-04-16 11:45:21 EDT
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
Comment 16 Adam Williamson 2010-04-23 12:26:52 EDT
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
Comment 17 Thomas Woerner 2010-04-27 10:00:34 EDT
Please have a look at #583986 - the update package is in testing.
Comment 18 Adam Williamson 2010-04-30 12:56:36 EDT
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
Comment 19 Martin Sivák 2010-05-03 04:14:26 EDT
No patch should be needed. It has to be tested though.
Comment 20 Thomas Woerner 2010-05-03 10:25:24 EDT
*** Bug 586685 has been marked as a duplicate of this bug. ***
Comment 21 Adam Williamson 2010-05-03 10:54:31 EDT
Setting to ON_QA, then - QA folks, we need to test this.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 22 Orion Poplawski 2010-05-03 12:39:41 EDT
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.
Comment 23 Thomas Woerner 2010-05-03 13:19:13 EDT
Please use "/usr/sbin/lokkit --selinux=enforcing" without quiet and nostart option for selinux only configuration.
Comment 24 Adam Williamson 2010-05-03 21:07:44 EDT
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
Comment 25 James Laska 2010-05-04 15:40:54 EDT
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
Comment 26 Adam Williamson 2010-05-04 18:51:12 EDT
is the fix in the updates.img we have available for test?

http://people.fedoraproject.org/~jwrdegoede/f13-updates.img
Comment 27 James Laska 2010-05-04 20:17:29 EDT
(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
Comment 28 Fedora Update System 2010-05-05 01:16:21 EDT
anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
Comment 29 Fedora Update System 2010-05-05 03:22:52 EDT
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
Comment 30 Kamil Páral 2010-05-05 05:15:19 EDT
(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
Comment 31 Adam Williamson 2010-05-05 07:58:41 EDT
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.
Comment 32 Thomas Woerner 2010-05-05 09:09:56 EDT
Please enable the Fedora 13 repo, it contains system-config-firewall-1.2.25-1, which is also needed.
Comment 33 Adam Williamson 2010-05-05 11:36:26 EDT
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.
Comment 34 Thomas Woerner 2010-05-05 12:03:21 EDT
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.
Comment 35 Adam Williamson 2010-05-05 12:29:04 EDT
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.
Comment 36 Adam Williamson 2010-05-05 12:36:26 EDT
just checked; the released anaconda 13.40-1 does indeed include this fix.
Comment 37 Adam Williamson 2010-05-05 12:58:22 EDT
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.
Comment 38 Jesse Keating 2010-05-05 14:39:34 EDT
Confirmed that it works with the new anaconda.  I get ssh enabled once again.
Comment 39 Orion Poplawski 2010-05-05 15:16:08 EDT
Works w/ Hans' updates.img for me.  No /etc/sysconfig/iptables with "firewall --disabled".  Thanks.
Comment 40 Adam Williamson 2010-05-05 17:42:29 EDT
Let's close this, then.
Comment 41 Fedora Update System 2010-05-06 02:54:58 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.