SCIENTIFIC-LINUX-USERS Archives

May 2007

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jan Iven <[log in to unmask]>
Reply To:
Date:
Mon, 14 May 2007 10:36:03 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
> By definition, linux rescue will only be used by someone on site so I
> don't see why it should assume SEL is enabled.  I think it should be
> disabled.  I realise that the Upstream Vendor is married to SEL but there
> are those of us who would rather not use it at all, particularly as we
> patch the kernels with alternatives.  Would there ever be a possibility of
> SL without SEL?

(you can turn it off at boot time via selinux=0). One problem I see with
turning it off in general for the rescue media is that weird things
happen when you reboot a SELinux-aware system with a non-SELinux kernel,
make changes to the file system and boot back into SELinux. SELinux uses
extended attributes inside the filesystem for the security context, if
these don't get updated properly (e.g. on copy/rename) things tend to
fail later. While these problems can typically get fixed by
"relabeling", troubleshooting takes some time if the box refuses to let
you in..

Since "boot to fix things on the file system" looks like a major use
case for the rescue disk, this would get people regularly.

A safer alternative to totally disabling SELinux would be to run the
rescue disk in non-enforcing mode. That way the attributes will get
updated, but SELinux stays out of the way (except for complaining a bit
now and then).

Regards
Jan

ATOM RSS1 RSS2