[Lustre-discuss] SELinux and lustre clients

Andreas Dilger adilger at sun.com
Wed Apr 1 16:40:35 PDT 2009


On Mar 17, 2009  14:51 -0400, Brian J. Murrell wrote:
> On Tue, 2009-03-17 at 10:56 -0400, Brock Palen wrote:
> > It has been stated on the list before that the lustre servers
> > are not compatible with SELinux but what about clients?
> 
> No, I don't believe so, and the bug you reference below further supports
> my belief about it.

The bug does contain a mention to "remove (or comment out) the lustre line
from policy/modules/kernel/filesystem.te".  Have you tried this?  If that
fixes the problem it could be pushed back to RHEL as a bugfix to placate
your users.

> > We have some post-processing desktops that are clients of our lustre  
> > system. We don't have control over this load, and they are dedicated  
> > to using SELinux.
> 
> Other than you hacking SELinux support into Lustre (and giving us the
> patch of course) I'm not sure what to suggest to/for you.  SELinux is
> just not a feature that has bubbled up in priority enough (yet) to have
> anyone work on it.
> 
> > Redhat says it is a lustre problem, after working on it a few months  
> > with them:
> > https://bugzilla.redhat.com/show_bug.cgi?id=489583
> 
> From what I've read, it would seem they are right.  I doubt you will get
> anyone that will argue that.  We just don't have the demand/funding (and
> hence the manpower) to implement it.

Looking at older kernels (2.6.5 SLES9, which is still supported on the
1.6.x codeline, sigh) we can't use security_d_instantiate() because it
directly calls d_instantiate(), which breaks the extra locking we need
for network invalidation of filenames.

It looks like this is fixed in 2.6.9 RHEL4 and later, so it might be
possible to add this call to ll_d_add() (though I have no idea at all
if other things are needed).  It seems the only troublesome area is
open(O_CREAT), which is where Lustre has to do gyrations to avoid
problems in older kernels.

It might be possible that these gyrations can be removed in newer kernels
and we become a "normal" VFS user, but it would need to be done on a later
Lustre release (e.g. 2.0) when we are only running on "modern" kernels
(e.g. 2.6.27 or whatever is needed to have a properly functioning VFS).

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.




More information about the lustre-discuss mailing list