Bug 907898

Summary:	Wrong selinux context on /var/lib/nfs/statd/sm
Product:	Red Hat Enterprise Linux 5	Reporter:	Josef Zimek <pzimek>
Component:	rgmanager	Assignee:	Ryan McCabe <rmccabe>
Status:	CLOSED ERRATA	QA Contact:	Cluster QE <mspqa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.10	CC:	ahoness, ccaulfie, cluster-maint, djansa, dvossel, dwalsh, eparis, jlayton, mjuricek, mmalik, steved
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	rgmanager-2.0.52-43.el5	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	959520 (view as bug list)		Environment:
Last Closed:	2013-09-30 22:37:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	928849, 959520, 967456

Description Josef Zimek 2013-02-05 13:47:36 UTC

Description of problem:

The problem is that the rpc.statd is not running:
rpc.statd[17919]: Version 1.0.9 Starting                                                                             
rpc.statd[17919]: rename (/var/lib/nfs/statd/sm to /var/lib/nfs/statd/sm.bak): Permission denied

I managed to resolve this by removing /var/lib/nfs/statd/sm.bak and then it can be started by service nfslock start.


The problem with rpc.statd only happens when there have been mounts and therefore there are files in /var/lib/nfs/statd/sm

With selinux off nfslock starts correct. Also I found that the latest update of nfs-utils something was changed in the behaviour of the sm and sm.bak directories (see BZ#782455). Maybe selinux wasn't taken ino account here.


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


How reproducible:
Always

Steps to Reproduce:
1.SELinux enforcing
2.NFS as a cluster service
3.Problem only occurs if you have a NFS share in a cluster. For some reason the cluster manager writes the nfs locks to the NFS share itself. But if this NFS share is also a home directory the selinux label is probably user_u:object_r:user_home_t. So if cluster manager copies these files on startup to /var/lib/nfs/statd/sm it still has the user_u:object_r:user_home_t context where nfslock expects system_u:object_r:var_lib_nfs_t:s0
  
Actual results:


Expected results:


Additional info:

Comment 3 Daniel Walsh 2013-03-05 17:04:22 UTC

What avc's are you seeing?

 matchpathcon /var/lib/nfs/statd/sm.bak
/var/lib/nfs/statd/sm.bak	system_u:object_r:var_lib_nfs_t:s0

Comment 4 Milos Malik 2013-03-18 15:19:24 UTC

Do you see any AVCs when reproducing the problem?

# ausearch -m avc -m selinux_err

Comment 8 Karel Srot 2013-04-09 12:30:06 UTC

Hi,
are we able to reproduce this bug in our environment?

Comment 11 Daniel Walsh 2013-04-10 18:11:56 UTC

So this is not an selinux issue but belongs to the script doing the cp.  One other solution would be to run restorecon after the copy.

Comment 14 RHEL Program Management 2013-05-03 09:08:38 UTC

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 16 Ryan McCabe 2013-05-20 19:18:59 UTC

Fix pending pull upstream at https://github.com/ryan-mccabe/resource-agents/commit/d32885baaeab0b58df42a5d52697e23ed6a14e52

Comment 24 errata-xmlrpc 2013-09-30 22:37:26 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1316.html