Bug 474100 - system-config-securitylevel misreports NFS4 as enabled when using specific "other ports" entries
system-config-securitylevel misreports NFS4 as enabled when using specific "o...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: system-config-securitylevel (Show other bugs)
5.2
i686 Linux
low Severity low
: rc
: ---
Assigned To: Thomas Woerner
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-02 03:26 EST by Garrett Ellis
Modified: 2013-04-12 15:58 EDT (History)
3 users (show)

See Also:
Fixed In Version: system-config-securitylevel-1.6.29.1-6.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-08 10:55:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Garrett Ellis 2008-12-02 03:26:33 EST
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727)

When system-config-securitylevel starts and determines the checked/unchecked values for each standard iptables rule offering, the NFS4 checkbox becomes checked if a rule permitting 2049/udp was manually entered into the "other ports" dialog. This is problematic for two reasons:

1) system-config-securitylevel defines the NFS4 offering as only 2049/tcp.
2) system-config-securitylevel does not remember the 2049/udp rule as being part of the "other ports" custom dialog.

The end result is that system-config-securitylevel loads with NFS4 checked and the "other ports" dialog is loaded with 2049/udp missing, effectively reversing the changes just made. 

Here is some additional information:

1) In all cases for researching this bug, system-config-securitylevel was run from a X terminal.
2) This is RHEL 5.2 (Tikanga) within VMWare Workstation 6.0.5-104988. The guest OS is 32-bit.
3) I found this while conducting RHEL5 installations from NFS. Since the installation GUI does not permit the use of TCP-only NFS, I needed to enable UDP NFS traffic in order to permit the client to install via an exported filesystem. 
4) uname -a: Linux mastermind 2.6.18-92.1.18.el5xen #1 SMP Wed Nov 5 09:30:07 EST 2008 i686 i686 i386 GNU/Linux.

Please contact me with any questions. I'll be glad to help.

Reproducible: Always

Steps to Reproduce:
1. Right-click X background, choose "Open Terminal".
2. Execute system-config-securitylevel.
3. Ensure NFS4 is unchecked. If it started checked, uncheck it, apply, OK, and rerun system-config-securitylevel.
4. Click "other ports" to expand the drop down.
5. Allow 2049/udp.
6. Apply the change, click OK.
7. "iptables -vnL" will show you that 2049/udp is now accepted.
8. system-config-securitylevel
9. Observe the check next to NFS4 and the missing rule from "other ports". This is the bug.
10. To confirm this, open another terminal and execute "iptables -vnL". You'll confirm that 2049/udp is accepted while 2049/tcp is nowhere to be found.

To isolate system-config-securitylevel's definition of NFS4 as 2049/tcp only, follow these steps:
1. system-config-securitylevel from a X terminal
2. if checked, uncheck NFS4, apply, OK.
3. iptables -vnL (there should be no 2049s)
4. system-config-securitylevel
5. check NFS4, apply, OK.
6. "iptables -vnL" now shows 2049/tcp but not 2049/udp.


Actual Results:  
The results have already been described. Please read "Steps to Reproduce" as well as "Details".

Expected Results:  
I expect any of the following:

1) system-config-securitylevel to include 2049/udp as part of the NFS4 definition.
2) system-config-securitylevel to recognize 2049/udp as separate from the NFS4 definition, thus preventing its elimination from the "other ports" dialog alongside the erroneous setting of NFS4 to "checked".

I've already described what I believe the software should have done. Please read "Expected Results".

Although this bug involves a firewall configuration tool, I have opted not to check "This report is security sensitive" since I cannot see it leading to a compromise of any services. If anything, this bug could prevent compromises since it will interfere with junior administrators who wish to configure NFS. :)
Comment 2 RHEL Product and Program Management 2009-03-26 13:03:57 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 3 RHEL Product and Program Management 2009-11-06 13:56:30 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 4 Thomas Woerner 2010-08-19 11:08:18 EDT
Fixed in system-config-securitylevel-1.6.29.1-6.el5.

Here is the build: https://brewweb.devel.redhat.com/buildinfo?buildID=141147
Comment 8 errata-xmlrpc 2010-09-08 10:55:18 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0686.html

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