Bug 199715

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

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

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.

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.

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.

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.

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.

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.

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.

Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

QE ack for 3.9.

Moving to "Documentation" component for release note tracking.

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