Bug 484544 - NFS shares can be written to even if "nfs_export_all_rw=off"
NFS shares can be written to even if "nfs_export_all_rw=off"
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Eric Paris
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 517000
  Show dependency treegraph
 
Reported: 2009-02-08 02:04 EST by Murray McAllister
Modified: 2015-01-04 17:35 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:01:30 EST
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 Murray McAllister 2009-02-08 02:04:46 EST
Description of problem:

Apologies if this is expected behavior.

* nfs_export_all_rw off
* nfs_export_all_ro on
* read-write permissions (rw) configured in "/etc/exports".
* other NFS related Booleans are off. See "Additional info" section.

With the above configuration, clients are able to write to NFS mounted shares.


Version-Release number of selected component (if applicable):

selinux-policy-3.5.13-41.fc10.noarch
selinux-policy-targeted-3.5.13-41.fc10.noarch
nfs-utils-1.1.4-7.fc10.i386
util-linux-ng-2.14.1-3.2.fc10.i386
rpcbind-0.1.7-1.fc10.i386

How reproducible:

Always (for me).

Steps to Reproduce:

On the system running the NFS service (from nfs-utils):

0. run "setsebool nfs_export_all_rw off" and "setsebool nfs_export_all_ro on".
1. mkdir /export (mine was labeled with the default_t type: drwxrwxrwx  root root system_u:object_r:default_t:s0   /export/).
2. add "/export *(rw)" to /etc/exports
3. run "tail -f /var/log/messages" or "tail -f /var/log/audit/audit.log".

Mount /export on a remote machine (mount server:/export /mountpoint). Confirm
the mount works as expected, and that write access is allowed. See denials on the system running the NFS service.
  
Actual results:

Clients can write to the NFS mounted shares.

Same denials as bug #484541 (<https://bugzilla.redhat.com/attachment.cgi?id=331224>).

nfs_export_all_ro is on but setroubleshoot browsers suggests turning nfs_export_all_ro on.


Expected results:

Write access denied since nfs_export_all_rw is off.

Additional info:

The system mounting and writing to /export was Fedora rawhide.

allow_ftpd_use_nfs --> off
allow_nfsd_anon_write --> off
httpd_use_nfs --> off
nfs_export_all_ro --> on
nfs_export_all_rw --> off
qemu_use_nfs --> off
samba_share_nfs --> off
use_nfs_home_dirs --> off
virt_use_nfs --> off
xen_use_nfs --> off
Comment 1 Daniel Walsh 2009-02-09 09:16:19 EST
I believe the problem here is the kernel is actually reading/writing the files, so you are not getting the denials you would expect.

Adding eric, to see if he agrees with this assessment.
Comment 2 Stephen Smalley 2009-09-04 09:31:21 EDT
nfsd kernel threads run in kernel_t presently.
If unconfined module is present, then kernel_t is unconfined and thus can read/write all files.
If unconfined module is removed, the kernel_t is not unconfined, and thus the nfs_export_* booleans are relevant.

Better solutions would be:
a) Put nfsd kernel threads into their own type, or
b) Have nfsd kernel threads switch to a type based on the NFS client (something that would come out of the labeled NFS work although you could also do something in the short term just by way of extending exports to support specifying per-client contexts and having the kernel use that information if present upon nfsd_setuser).
Comment 3 Bug Zapper 2009-11-16 04:46:55 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Bug Zapper 2010-11-04 07:31:42 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2010-12-05 02:01:30 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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