Bug 489583 - files on Lustre filesystem are unlabeled_t
files on Lustre filesystem are unlabeled_t
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Red Hat Kernel Manager
Red Hat Kernel QE team
:
Depends On:
Blocks: 533192
  Show dependency treegraph
 
Reported: 2009-03-10 15:11 EDT by Issue Tracker
Modified: 2010-10-23 04:15 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-05 10:14:39 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 Issue Tracker 2009-03-10 15:11:59 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Jeff Bastian 2009-03-10 15:48:02 EDT
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)
Comment 4 Eric Paris 2009-03-10 15:53:30 EDT
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.
Comment 5 Jeff Bastian 2009-03-10 16:19:21 EDT
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.

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