This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 486069 - Trying to mount NFS share with Rawhide is blocked by selinux
Trying to mount NFS share with Rawhide is blocked by selinux
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-17 23:29 EST by Adam Williamson
Modified: 2009-02-18 14:32 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-18 10:04:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2009-02-17 23:29:42 EST
Unfortunately I don't know when this last worked, but, trying to mount an NFS share with Rawhide today which has worked before, I get:

[root@adam adamw]# service netfs start
Mounting NFS filesystems:  mount.nfs: Address family not supported by protocol
                                                           [FAILED]

Turns out selinux is blocking it:

SELinux is preventing mount.nfs (rpcd_t) "signal" mount_t. 

SELinux denied access requested by mount.nfs. It is not expected that this access is required by mount.nfs and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. 

Raw Audit Messages :

node=adam.local.net type=AVC msg=audit(1234931144.932:73): avc: denied { signal } for pid=16062 comm="mount.nfs" scontext=system_u:system_r:rpcd_t:s0 tcontext=unconfined_u:system_r:mount_t:s0 tclass=process 

node=adam.local.net type=AVC msg=audit(1234931144.932:73): avc: denied { signal } for pid=16062 comm="mount.nfs" scontext=system_u:system_r:rpcd_t:s0 tcontext=unconfined_u:system_r:mount_t:s0 tclass=process 

node=adam.local.net type=SYSCALL msg=audit(1234931144.932:73): arch=c000003e syscall=165 success=no exit=-97 a0=7fffaac4af63 a1=2272040 a2=411f2a a3=2 items=0 ppid=16061 pid=16062 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="mount.nfs" exe="/sbin/mount.nfs" subj=unconfined_u:system_r:mount_t:s0 key=(null)
Comment 1 Adam Williamson 2009-02-17 23:30:44 EST
Server is running Mandriva 2009, nfs-utils 1.1.3, I'm not actually sure if it's the kernel or userspace NFS implementation being used, it's never given me trouble before.
Comment 2 Steve Dickson 2009-02-18 06:32:20 EST
What nfs-utils version are you using? nfs-utils-1.1.4-18.fc11?
Comment 3 Daniel Walsh 2009-02-18 10:04:16 EST
Steve, I just added the ability to send the signal back to the mount command.  I noticed that we had policy that allows mount to start the rpcd daemon so it must be sending a signal back to its parent which is causing this AVC.

Fixed in selinux-policy-3.6.6-4
Comment 4 Adam Williamson 2009-02-18 12:34:33 EST
Steve: yep, indeed. Sorry I forgot to specify that.

Daniel: Thanks, I'll test and confirm the fix shortly.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 5 Adam Williamson 2009-02-18 13:57:00 EST
Well, confirmed that I no longer get an selinux failure when trying to start the NFS share after grabbing this update from Koji, but I still get the "mount.nfs: Address family not supported by protocol" error and it doesn't work :\. That's clearly a different bug, though, so I confirm that this one is fixed. Thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Adam Williamson 2009-02-18 14:32:36 EST
For the record, the underlying problem indeed turns out to be nothing selinux-related, it's to do with the ipv6 kernel module.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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