Bug 199715 - CVE-2007-0004 open() succeeds incorrectly on root_squash NFS when mounted with noacl
Summary: CVE-2007-0004 open() succeeds incorrectly on root_squash NFS when mounted wit...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: Documentation
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Don Domingo
QA Contact: Brian Brock
URL:
Whiteboard: impact=moderate,source=redhat,reporte...
Depends On:
Blocks: 202654 RHEL3u9_relnotes
TreeView+ depends on / blocked
 
Reported: 2006-07-21 15:23 UTC by Issue Tracker
Modified: 2009-08-20 03:28 UTC (History)
10 users (show)

Fixed In Version: 3.9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-08 21:05:56 UTC
Target Upstream Version:


Attachments (Terms of Use)
patch 1 (320 bytes, patch)
2006-07-31 13:32 UTC, Jeff Layton
no flags Details | Diff
patch 2 (1.79 KB, patch)
2006-08-15 18:25 UTC, Jeff Layton
no flags Details | Diff

Description Issue Tracker 2006-07-21 15:23:39 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2006-07-21 15:23:52 UTC
Customer has a auto-mounted NFS share /kickstart from NetApp filer.

--snip--
netappfiler> exportfs
/ks      -actual=/some/vol/ks,sec=sys,rw,root=a.b.c:b.b.c:c.b.c 
--snip--
.. machine is not in "root" allowed list


mount -v
------------
automount(pid3817) on /kickstart type autofs (rw,fd=5,pgrp=3817,minproto=2,maxproto=4)

ls -al /kickstart/etc/testfile
-rw-------    1 root     other     20 Mar 20 14:00 /kickstart/etc/testfile

more /kickstart/etc/testfile
cat /kickstart/etc/testfile
cat: /kickstart/etc/testfile: Input/output error

mount -v
automount(pid3817) on /kickstart type autofs (rw,fd=5,pgrp=3817,minproto=2,maxproto=4)
filer1:/vol/admin/local/kickstart/etc on /kickstart/etc type nfs (ro,tcp,noacl,noacl,rsize=8192,wsize=8192,addr=10.1.17.10)

---
Why does the "more" command not complain about 'permission denied' ?
Why did the "cat" give an I/O error instead of a  'permission denied' ?
This event sent from IssueTracker by jlayton  [Support Engineering Group]
 issue 90713

Comment 2 Issue Tracker 2006-07-21 15:24:05 UTC
Customer:
---------
>So the behavior they're seeing sounds correct and reasonable to me  
>given the situation.

Please understand, that RHEL3 and RHEL4 behave different!
Hopefully only behavior of RHEL4 sounds correct/reasonable for you:
RHEL4:
# ll /ks/etc/testfile
-rw------- 1 root other 20 Mar 20 14:00  /ks/etc/testfile
# more /ks/etc/testfile
/ks/etc/testfile: Permission denied
# cat /ks/etc/testfile
/ks/etc/testfile: Permission denied
RHEL3:
# ll /ks/etc/testfile
-rw------- 1 root other 20 Mar 20 14:00  /ks/etc/testfile
# more /ks/etc/testfile
(no output, expected: "/ks/etc/testfile: permission denied")
# cat /ks/etc/testfile
cat: /ks/etc/testfile: Input/output error

/ks/etc/tesfile is nfs-mounted volume with options
"ro,noacl,rsize=wsize=8192",
either from solaris/VxFS or netapp-filer or RHEL4-nfs-server.

So I'm asking once again to fix this "noacl"-problem/bug on RHEL3,
(as it has been done in RHEL4),  
to not have to think about switching off
"rootsquash"-option on our nfs-servers and its implications. 

Internal Status set to 'Waiting on SEG'
Status set to: Waiting on Tech

This event sent from IssueTracker by jlayton  [Support Engineering Group]
 issue 90713

Comment 4 Jeff Layton 2006-07-28 12:49:45 UTC
Added some code around the readpage: section of do_generic_file_read. It looks
like the EIO comes from there. Apparently, this returns 0:

           error = mapping->a_ops->readpage(filp, page);


...and then generic_file_readahead() doesn't set F_ATOMIC in the flags, so we
return -EIO:

do_generic_file_read: setting desc error on read of testfile to -5

This section of code is quite a bit different upstream, so still looking at what
it does differently.


Comment 5 Jeff Layton 2006-07-28 15:20:33 UTC
2.4.32 never even calls do_generic_file_read for the file, so some of the
calling functions must be returning EACCES before it even gets to that point.


Comment 7 Jeff Layton 2006-07-31 13:32:20 UTC
Created attachment 133319 [details]
patch 1

This patch seems to correct the problem and looks to be the right approach.
When noacl is specified, RHEL3 skips the NFS ACCESS call to the server and
relies on vfs_permission, which just uses the mode bits. This is obviously
wrong in a root squash situation.

The 2.4.32 nfs_permission routine is very different from the one in RHEL3, but
I've not been able to track down the upstream patches that made those changes.
Still, when it comes to this situation it seems to follow the same logic.

Comment 8 Jeff Layton 2006-07-31 13:48:28 UTC
Actually, it looks like that line was changed as part of the NFS ACL patch, and
that patch never went upstream. So patch 1 should be ok.


Comment 12 Jeff Layton 2006-08-15 13:54:39 UTC
Changing back to ASSIGNED based on feedback from Ingo M. I'm going to respin
this patch so that this behavior is contingent on a new mount option noacl_safe.


Comment 13 Jeff Layton 2006-08-15 18:25:16 UTC
Created attachment 134240 [details]
patch 2

This patch adds a "noacl_safe" mount option for nfs, and makes the "correct"
behavior contingent upon it. The regular noacl option should behave as it has
up until now.

I'll also clone this BZ and post the corresponding patch for mount to it.

Comment 15 Jeff Layton 2006-08-15 19:28:55 UTC
Peter S. indicated that this is just a bug plain and simple, and patch 2 really
serves no purpose. So, I'll stick with proposing patch 1.


Comment 22 RHEL Program Management 2006-12-18 23:41:14 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

Comment 35 Jay Turner 2007-02-20 12:47:16 UTC
QE ack for 3.9.

Comment 46 Ernie Petrides 2007-03-13 23:06:52 UTC
Moving to "Documentation" component for release note tracking.


Comment 49 Issue Tracker 2007-06-29 11:10:56 UTC
There have been no updates to this issue in the past month. This issue will
now be closed due to inactivity. If this is in error, please reopen the
issue and check to make sure that it is current and in the proper status.
If the issue is something which is on a longer timeline than a month,
please change the status to one of the long term selections to avoid
closure due to inactivity.
This event sent from IssueTracker by AutoCloser  [EMEA Production
Escalation]
 issue 90713


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