Bug 199715 - CVE-2007-0004 open() succeeds incorrectly on root_squash NFS when mounted with noacl
CVE-2007-0004 open() succeeds incorrectly on root_squash NFS when mounted wit...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: Documentation (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Don Domingo
Brian Brock
impact=moderate,source=redhat,reporte...
: Documentation, Reopened, Security
Depends On:
Blocks: 202654 RHEL3u9_relnotes
  Show dependency treegraph
 
Reported: 2006-07-21 11:23 EDT by Issue Tracker
Modified: 2009-08-19 23:28 EDT (History)
10 users (show)

See Also:
Fixed In Version: 3.9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-08 17:05:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Issue Tracker 2006-07-21 11:23:39 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2006-07-21 11:23:52 EDT
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 11:24:05 EDT
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 08:49:45 EDT
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 11:20:33 EDT
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 09:32:20 EDT
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 09:48:28 EDT
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 09:54:39 EDT
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 14:25:16 EDT
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 15:28:55 EDT
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 Product and Program Management 2006-12-18 18:41:14 EST
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 
Comment 35 Jay Turner 2007-02-20 07:47:16 EST
QE ack for 3.9.
Comment 46 Ernie Petrides 2007-03-13 19:06:52 EDT
Moving to "Documentation" component for release note tracking.
Comment 49 Issue Tracker 2007-06-29 07:10:56 EDT
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.