Bug 489583
Summary: | files on Lustre filesystem are unlabeled_t | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Issue Tracker <tao> |
Component: | kernel | Assignee: | Red Hat Kernel Manager <kernel-mgr> |
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.3 | CC: | dmair, dwalsh, eparis, jbastian, tao |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-01-05 15:14:39 UTC | Type: | --- |
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: | 533192 |
Description
Issue Tracker
2009-03-10 19:11:59 UTC
Description of problem: This is a follow-up to the tech-list discussion. http://post-office.corp.redhat.com/archives/tech-list/2009-January/msg00429.html On a lustre client, the files on the lustre filesystem have unlabeled_t type. They should have nfs_t. The system has selinux-policy-2.4.6-216.el5 which resolves the conflict mentioned in the above tech-list discussion. The mount point itself is correct with nfs_t. # ls -ldZ /mnt drwxr-xr-x root root system_u:object_r:mnt_t /mnt # mount -t lustre 10.65.7.135@tcp0:/lustre /mnt # grep lustre /proc/mounts 10.65.7.135@tcp:/lustre /mnt lustre rw,acl 0 0 # dmesg | egrep -i 'selinux.*lustre' SELinux: initialized (dev lustre, type lustre), uses genfs_contexts # ls -ldZ /mnt drwxr-xr-x root root system_u:object_r:nfs_t /mnt # ls -lZ /mnt/a -rw-r--r-- root root system_u:object_r:unlabeled_t /mnt/a Attempting to "fix" the files with restorecon changes them to default_t: # restorecon -v /mnt/a restorecon reset /mnt/a context system_u:object_r:unlabeled_t:s0->system_u:object_r:default_t:s0 Programs like 'vim' have problems in this state. Editing an existing file causes vim to choke when creating a swap file. # grep sealart /var/log/messages | tail -1 Mar 11 01:02:12 dhcp7-136 setroubleshoot: SELinux is preventing vim from creating a file with a context of unlabeled_t on a filesystem. For complete SELinux messages. run sealert -l d9791052-da6a-4b84-8ff9-6d4c682e7e86 See below for the full sealert text. Version-Release number of selected component (if applicable): selinux-policy-2.4.6-216.el5 selinux-policy-devel-2.4.6-216.el5 selinux-policy-targeted-2.4.6-216.el5 lustre-1.6.7-2.6.18_92.1.17.el5_lustre.1.6.7smp lustre-modules-1.6.7-2.6.18_92.1.17.el5_lustre.1.6.7smp How reproducible: every time Steps to Reproduce: 1. create a Luster server and client http://wiki.lustre.org/index.php?title=Lustre_Quick_Start NOTE: SELinux must be disabled on the server 2. on the client, mount a Lustre export from the server Actual results: SELinux contexts on files show up as unlabeled_t Expected results: files have nfs_t Additional info: # sealert -l d9791052-da6a-4b84-8ff9-6d4c682e7e86 Summary: SELinux is preventing vim from creating a file with a context of unlabeled_t on a filesystem. Detailed Description: SELinux is preventing vim from creating a file with a context of unlabeled_t on a filesystem. Usually this happens when you ask the cp command to maintain the context of a file when copying between file systems, "cp -a" for example. Not all file contexts should be maintained between the file systems. For example, a read-only file type like iso9660_t should not be placed on a r/w system. "cp -P" might be a better solution, as this will adopt the default file context for the destination. Allowing Access: Use a command like "cp -P" to preserve all permissions except SELinux context. Additional Information: Source Context root:object_r:unlabeled_t Target Context system_u:object_r:nfs_t Target Objects .file.swn [ filesystem ] Source vim Source Path /usr/bin/vim Port <Unknown> Host dhcp7-136.pnq.redhat.com Source RPM Packages vim-enhanced-7.0.109-4.el5_2.4z Target RPM Packages Policy RPM selinux-policy-2.4.6-216.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name filesystem_associate Host Name dhcp7-136.pnq.redhat.com Platform Linux dhcp7-136.pnq.redhat.com 2.6.18-92.1.17.el5 #1 SMP Wed Oct 22 04:19:07 EDT 2008 i686 i686 Alert Count 1 First Seen Wed Mar 11 01:02:10 2009 Last Seen Wed Mar 11 01:02:10 2009 Local ID d9791052-da6a-4b84-8ff9-6d4c682e7e86 Line Numbers Raw Audit Messages host=dhcp7-136.pnq.redhat.com type=AVC msg=audit(1236713530.371:140): avc: denied { associate } for pid=3150 comm="vim" name=".file.swn" scontext=root:object_r:unlabeled_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem host=dhcp7-136.pnq.redhat.com type=SYSCALL msg=audit(1236713530.371:140): arch=40000003 syscall=5 success=no exit=-13 a0=9b63128 a1=280c2 a2=180 a3=280c2 items=0 ppid=3128 pid=3150 auid=0 uid=2000 gid=2000 euid=2000 suid=2000 fsuid=2000 egid=2000 sgid=2000 fsgid=2000 tty=pts0 ses=1 comm="vim" exe="/usr/bin/vim" subj=root:system_r:unconfined_t:s0-s0:c0.c1023 key=(null) so this is really a lustre problem. They appear to have completely written their own VFS implementation and aren't making the requisite calls to security_d_instantiate every time they hook an inode and a dentry together. This explains why the superblock and the root inode are labeled correctly (they are done at mount time) but the subsequent inodes are never labeled at all. Policy does not appear to have a SECURITY_FS_USE_MNTPOINT type construct (which I'm not sure would work either to be honest) Until lustre gets it's act together and actually either calls the vfs d_instantiate function or calls security_d_instantiate there is nothing we can do and selinux is just going to ahve to be turned off. I'm wondering, then, if we should remove (or comment out) the lustre line from policy/modules/kernel/filesystem.te genfscon lustre / gen_context(system_u:object_r:nfs_t,s0) The line implies that Lustre should work similar to NFS wrt SELinux, but it doesn't work due to Lustre's implementation. Furthermore, in my testing, there does seem to be some limited support for Extended Attributes in Lustre. For example, if I run restorecon or chcon on the client, then the server sees those changes and 'ls -Z' on the server shows the new context. But if you unmount & remount on the client, it goes back to unlabeled_t. So, if Lustre ever does fully support SELinux, then the above line in the policy will cause problems. In the meantime, it's not helping, so maybe we should just remove it. |