Bug 613862
| Summary: | iptables -L creates zero-length output when written direct to file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Donaldson <idonaldson0> | ||||
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 13 | CC: | idonaldson0, twoerner | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | selinux-policy-3.7.19-65.fc13 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-10-19 07:06:20 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: | |||||||
| Attachments: |
|
||||||
Please check if there was a SELinux error. Yeah that did occur to me too, but I can't see any evidence of a SELinux reported error related to this: # date Tue Jul 13 22:12:30 EST 2010 # ls -l /var/log/audit/audit.log -rw-------. 1 root root 971950 Jul 13 22:10 /var/log/audit/audit.log # iptables -L -v -n > /tmp/kj # ls -l /var/log/audit/audit.log -rw-------. 1 root root 971950 Jul 13 22:10 /var/log/audit/audit.log # date Tue Jul 13 22:12:49 EST 2010 # ls -l /tmp/kj -rw-r--r--. 1 root root 0 Jul 13 22:12 /tmp/kj This happens on fc13 also (just yum upgraded a fc12 system)
# uname -a
Linux MYHOST 2.6.33.6-147.fc13.i686.PAE #1 SMP Tue Jul 6 22:24:44 UTC 2010 i686 i686 i386 GNU/Linux
# rpm -q iptables
iptables-1.4.7-2.fc13.i686
# rpm -q bash
bash-4.1.7-1.fc13.i686
# ls -l /tmp/va
ls: cannot access /tmp/va: No such file or directory
# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1708 422K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
21 1260 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
983 162K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 1598 packets, 281K bytes)
pkts bytes target prot opt in out source destination
# iptables -L -v -n > /tmp/va
# ls -l /tmp/va
-rw-r--r--. 1 root root 0 Jul 16 10:34 /tmp/va
# cat /tmp/va
# strace -f -o /tmp/z1 bash -c 'iptables -L -v -n > /tmp/zq'
# ls -l /tmp/zq
-rw-r--r--. 1 root root 0 Jul 16 10:35 /tmp/zq
Attached is the strace output.
Created attachment 432266 [details]
strace output for last post
This is a SELinux error and it is set to do not audit. Reassigning to selinux-policy-targeted. iptables-save | cat > /tmp/xx will work. Miroslav we need a unconfined_iptables_t domain, that transition etc_t to system_conf_t. Fixed in selinux-policy-3.7.19-64.fc13 selinux-policy-3.7.19-65.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-65.fc13 selinux-policy-3.7.19-65.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 selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-65.fc13 selinux-policy-3.7.19-65.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: If you do this: iptables -L -v -n > somefile the size of somefile is always zero. However if you write it to the terminal or pipe it via cat, you see it all. eg: iptables -L -v -n - works fine iptables -L -v -n | cat > somefile - works fine strace of iptables shows the write(1, ...) working fine; several kilobytes of data is being written but after iptables ends, there is nothing in the file. This works fine on RHEL5 and fc7, but not fc12. Haven't tried others. Version-Release number of selected component (if applicable): FC12 $ rpm -q iptables iptables-1.4.5-1.fc12.i686 $ uname -a Linux MYHOST 2.6.32.14-127.fc12.i686.PAE #1 SMP Fri May 28 04:47:04 UTC 2010 i686 i686 i386 GNU/Linux also Linux MYOTHERHOST 2.6.32.14-127.fc12.x86_64 #1 SMP Fri May 28 04:30:39 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux How reproducible: 100% Steps to Reproduce: # iptables -L -v -n > /tmp/xx # ls -l /tmp/xx -rw-r--r--. 1 root root 0 Jul 13 01:21 /tmp/xx # iptables -L -v -n | cat > /tmp/xx # ls -l /tmp/xx -rw-r--r--. 1 root root 34045 Jul 13 01:21 /tmp/xx # strace -e write iptables -L -v -n > /tmp/xx write(1, "Chain INPUT (policy DROP 7 packe"..., 4096) = 4096 write(1, " 0.0.0.0/0 tcp d"..., 4096) = 4096 write(1, ".0/24 0.0.0.0/0 t"..., 4096) = 4096 write(1, ".122.0/23 0.0.0.0/0 "..., 4096) = 4096 write(1, "7.189.0.0/19 0.0.0.0/0 "..., 4096) = 4096 write(1, " 91.194.0.0/23 0.0.0.0/0"..., 4096) = 4096 write(1, " 91.213.72.0/24 0.0.0"..., 4096) = 4096 write(1, ".0/0 state RELATED,EST"..., 4096) = 4096 write(1, " 0.0.0.0/0 tcp flags:0"..., 1277) = 1277 # ls -l /tmp/xx -rw-r--r--. 1 root root 0 Jul 13 01:23 /tmp/xx A full strace output doesn't seem to reveal anything else going on special with fd #1 (like a truncate-on-close option or something) And just to prove its not bash... # echo boo > /tmp/xx # ls -l /tmp/xx -rw-r--r--. 1 root root 4 Jul 13 01:27 /tmp/xx # sh -c '/bin/echo bar' > /tmp/xx # ls -l /tmp/xx -rw-r--r--. 1 root root 4 Jul 13 01:27 /tmp/xx # cat /etc/group > /tmp/xx # ls -l /tmp/xx -rw-r--r--. 1 root root 1050 Jul 13 01:28 /tmp/xx # ls -l /etc/group -r--r--r--. 1 root root 1050 Jun 22 23:56 /etc/group Sounds like a wierd kernel bug to me. Expected results: direct output should be the same as piped via cat Additional info: