Drawing lessons from fatal SELinux bug #1054350
kevin.kofler at chello.at
Sat Jan 25 20:51:54 UTC 2014
Dominick Grift wrote:
> No, that is a different discussion.
Nonsense. That SELinux should be disabled is the whole point of this thread
(I know, I have started it!), all the suggestions (in the various
subthreads) of how to paper over the problem are off topic.
> Disabling SELinux does nothing to solve this.
Oh sure it does. It eliminates this whole class of breakage (critical
components unable to do their job because SELinux gets in their way) once
and for all. This type of breakage keeps occurring, in fact one instance is
still ongoing in Rawhide while we're discussing this:
Disable SELinux and nothing will keep those components (RPM, display
managers, etc.) from doing their work.
> If anything, to me this is confirmation of why we need a good SELinux
> implementation. If this would happen to any other component then a good
> SELinux implementation could have contained the damage caused by issues
> just like this one.
You don't seem to understand at all what SELinux is (it is not a tool
magically able to fix bugs, its only purpose is to keep programs from doing
> The SELinux experience can, in my view be improved, and i believe your
> problem is not with SELinux itself but with how it is
> configured/implemented by default.
… nor what it can or cannot do. (No amount of configuration can make SELinux
do anything other than block (i.e. break) things.)
> I just believe that a little team coordination, and a little more care
> can go a long way, and that that is likely more efficient than trying to
> create tests that would catch all of the bugs which sounds like utopia
> to me.
> I am not saying that the tests can't be improved or that they should not
> be improved. It's just that in this case a little bit more care and a
> double check by another involved party would probably have prevent this,
> and similar other issues, in my view.
Sure, dropping autokarma could help (and should be done in any case, that
Bodhi "feature" never made any sense), but ultimately there's no way around
disabling SELinux. Enabling it by default in Fedora has always been a
More information about the devel